OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm-editors] FW: [chairs] Draft ASIS under review: mandatory policy? Please review and comment by 1 March


Exactly my drift...

Glad to know that I've a reputation to uphold as a trouble-maker ;-)

Peter
-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: 20 February 2006 23:55
To: peter@justbrown.net
Cc: 'Duane Nickull'; soa-rm-editors@lists.oasis-open.org
Subject: Re: [soa-rm-editors] FW: [chairs] Draft ASIS under review:
mandatory policy? Please review and comment by 1 March

Peter,

I haven't read the proposals but something in the review request didn't seem
comforting.  Another problem of tight semantics in the naming is what
happens when the world changes and you need to revise the relationships?  Do
you change everything's name (and thus break all previous links) or do you
have groups of things in one naming conventions and other groups in others
and ... why did we do this in the first place?

At this point, I'm inclined to leave the clamoring to your capable hands.
If there is anything I can specifically help with, please let me know.

Ken

On Feb 20, 2006, at 5:14 PM, Peter F Brown wrote:

> Ken:
> spot on with the question.
>
> I was involved in an earlier review cycle, and even discussed parts of  
> it
> with Duane in Vancouver last year: I had thought that my views were a  
> bit
> odd-ball until speaking with Duane and, plucking up courage and  
> talking with
> more people, realised soon that there were very few people that  
> supported
> the proposals.
>
> My main objection has been, simply stated, that the effort to create a
> naming scheme based on (some of the)semantics of the artifact always
> outweighs the benefits.
>
> I do think that it is worth replying, and I will be making a  
> submission: it
> is interesting that Robin has written offlist to a number of people,
> including myself (maybe you too Duane?), asking that they respond,
> suggesting a certain nervousness on his part, or others, regarding its
> implementability.
>
> In summary, while I welcome the move towards a mandatory set of  
> metadata
> (caveat: the bloody things have a habit of changing over time), I do  
> not
> accept that that such metadata should determine the naming of an  
> artifact.
>
> More to the point, I think the naming convention will be top heavy and
> ultimately confusing and unworkable, with a resultant soup of samizdat
> approaches by more practical minded TCs...
>
> In more "information architecture" terms: metadata represents  
> properties of
> a relationship between two artifacts (often one abstract and another
> concrete), and not properties of the artifact itself.
>
> For example: we will often casually state that document x is version 1;
> whereas the correct statement would be that document x (concrete  
> artifact)
> represents version 1 of a particular work y (abstract artifact).
>
> RDF triples and Topic Maps handle these concepts very well.
>
> The important point to note is that often the *artifact* does not  
> change,
> whereas the nature and properties of its relationship with other  
> artifacts
> does: a single document can change "status" from a draft to a final  
> document
> without a byte of data changing. Equally an "abstract artifact", say a
> committee specification can have associations with several documents,  
> each
> representing a different property or set of properties (e.g. draft,  
> final,
> in English, in PDF, in unofficial translation in Chinese in ODF, etc).
>
> On my own website I've eliminated semantics completely from filenaming
> conventions, and merely have two series of numbers to represent "object
> concepts" (this presentation, that article, my resume), the URLs of  
> which
> are never changed once attributed, and actual content pages (when  
> content
> changes, it is a new file, and given a new filename). What changes is  
> the
> relationship, and thus the "triple". This means that as long as links  
> are
> only ever made to the concept URLs, the user is always directed to the  
> most
> recent content page, and there is no such thing as a dead link...I  
> digress:
> I will be presenting these sorts of arguments to TAB in the hope tat  
> they
> will end their folly...
>
> On a less kind note: where are the information scientists or trained
> librarians in the group that cooked up this draft?
>
> Peter
>
> -----Original Message-----
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: 20 February 2006 21:12
> To: Duane Nickull
> Cc: soa-rm-editors@lists.oasis-open.org
> Subject: Re: [soa-rm-editors] FW: [chairs] Draft ASIS under review:
> mandatory policy? Please review and comment by 1 March
>
> Has anyone been involved in the process or reviewed previous versions?
> Is this routine stuff or does it have the potential to be annoying but  
> not
> commensurately productive overhead in the future?
>
> Ken
>
> On Feb 20, 2006, at 3:07 PM, Duane Nickull wrote:
>
>> We need to respond.
>>
>> D
>>
>> *******************************
>> Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT
>> http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical
>> Committee Personal Blog - http://technoracle.blogspot.com/
>> *******************************
>>
>>
>> -----Original Message-----
>> From: James Bryce Clark [mailto:jamie.clark@oasis-open.org]
>> Sent: Friday, February 17, 2006 4:11 PM
>> To: chairs@lists.oasis-open.org
>> Subject: [chairs] Draft ASIS under review: mandatory policy? Please
>> review and comment by 1 March
>>
>> TC leadership:
>>
>>      Please take a careful look at the current member review draft of
>> the "OASIS Standard Artifact Identification Scheme (ASIS)" at [1], and
>> ask your editors and other interested TC members to do the same.  Our
>> Board of Directors plans to consider in March whether to make it, or
>> portions of it, mandatory policy after the current review is
>> completed.
>>
>>      Previous versions of this document were called "Artifact
>> Identification Requirements" and "Artifact Naming Guidelines", and
>> were the subject of an earlier review in June 2005 [2].  This proposed
>> policy would provide the technical details behind the "file naming
>> scheme" rule described in Section 2.18 of the TC Process:
>>
>>> "... All documents and other files produced by the TC, including
>>> specifications at any level of approval, must use the OASIS file
>>> naming scheme, and must include the OASIS copyright notice. ..."
>>
>> The Board plans to take into account the input from this second
>> review, and any recommendations the TAB makes as a result, when it
>> considers the document in March.
>>
>>      The document itself, and a disposition log of comments from the
>> 2005
>> review, can be found at the links listed in [1].  Please provide your
>> feedback between now and the deadline for comments, 1 March 2006.
>>
>>      Thanks and best regards  JBC
>>
>> [1]
>> http://lists.oasis-open.org/archives/oasis-member-discuss/200602/
>> msg00000.ht
>> ml
>> [2]
>> http://lists.oasis-open.org/archives/tc-announce/200507/msg00001.html
>>
>>
>>
>
> ----------------------------------------------------------------------- 
> -
> ------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:        703-983-1379
> McLean VA 22102-7508
>
>
>
>

------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]