Re: [chairs] Oasis document identifiers - conclusion?

[Karl Best <karl.best@oasis-open.org>]

Chairs:

I've been avoiding getting into this conversation because I didn't want 
to sound like I was dictating to you what you should come up with on the 
doc naming scheme. But Eve and I have had some off-line conversation and 
she suggested that I share what I said with you.

Perhaps once a spec is approved as an OASIS Standard we could just 
prefix whatever scheme is used within the TC with some designator that 
the spec is an OS with the date approved and sequence. Eve had wondered 
if we could just start sequentially with the first OS, but I think that 
it would make more sense to put the date in it. So perhaps we could have

    OS-2002-5-<whatever the TC calls it>

for the fifth OS approved during 2002. If the spec has multiple parts 
perhaps it could be called OS-2002-5a, OS-2002-5b, etc.

Does this make sense? (Again, I don't want to dictate what this looks 
like; these are just my suggestions.)

Kathryn brings up metadata. Good point. We will have some means of 
attaching metadata to files (the files will be stored in a repository 
with some metadata capabilities), so not all of the metadata needs to be 
present in the filename, but it helps to put *some* information there. 
OASIS will be implementing the Kavi system to provide a lot of 
functionality that TCs have been needing for a long time, and Kavi 
includes a document repository. We're also making plans for a registry 
of standards development information, starting with OASIS TC 
information, that will include specifications and glossary terms 
produced by TCs. This registry will use the Standards Registry metadata 
that was created by the StdsREg committee that I am a member of. I hope 
to be able to provide a bit more information about both of these shortly.

-Karl




Breininger, Kathryn R wrote:
> Through this string of email, there have been many suggestions about the 
> kind of information that should or should not be included in the file 
> name.  As a result, it is obvious that there are differing opinions on 
> what is important to include if the file name is the only source of 
> information for a document.  Metatags associated with a file, or a 
> database as suggested by James Keane would solve these issues, providing 
> various ways for users to find and retrieve documents based on what they 
> specifically are looking for (documents from a particular TC, documents 
> of a particular status, documents from a particular time or date, 
> etc.).  There are many tools available for building a small database 
> that could be used to catalog the documents and provide various search 
> and retrieval access points.  Part of the submission of a document could 
> be to have the editors begin to fill in the catalog record for a 
> document, providing most if not all the information needed (date, 
> version, TC, status, description, keywords, editor, etc.).  This doesn't 
> address the file naming issue necessarily, but does address the various 
> issues related to what information is important to people, and how they 
> would like to be able to retrieve it.
> 
>     -----Original Message-----
>     From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
>     Sent: Monday, January 06, 2003 1:42 PM
>     To: chairs@lists.oasis-open.org
>     Subject: Re: [chairs] Oasis document identifiers - conclusion?
> 
>     I agree about not overloading file names. It would seem to me
>     a better solution to let the file name be most anything a given TC
>     wants it to be, and instead to let users rely on a set of tagged
>     elements of a structure that could adequately describe the attributes
>     of a document.
> 
>     Such a structure could be managed and maintained by OASIS and
>     searched through a web page. A user then might retrieve all of the
>     standards, all the CSs, etc. This approach would not need to rely
>     on the good behavior of so many people across all of the TCs,
>     which may tend to be problematic.
> 
>     Phil
> 
>     jkeane wrote:
> 
>>The second suggested format [TC-Phase-StandardName-Version]makes sense
>>because it goes from the general to the specific.
>>
>>You can solve the classic database sorting problem by have multiple tags or
>>fields in  a catalog database. I had circulated a schematic and a list of
>>suggested fields prior to the Kavi meeting, but was unable to attend. Does
>>Kavi have any pre-existing workable solution to offer?  Are they on this
>>list? Are there some folks with Information Science or Wired Librarian skill
>>who should be involved with this discussion?.
>>
>>A file name, however elegantly framed, has not been not enough to satisfy
>>the queries we have gotten in LegalXML. This is particularly true of queries
>>by outsider who have trouble figuring out what we are doing. We also have a
>>lot of resources beside formal documents we should share with each other.
>>
>>Having a catalog database that can dynamically generate look-up table and
>>other user aids on various OASIS and committee web pages will allow reports
>>that can be specific to a sub-committee, to multiple sub-committees or cut
>>across committees, such as all drafts and final documents affecting
>>eCommerce or security. Without a database, we need to post multiple items to
>>various parts of the site, and then keep them synchronized as new drafts
>>appear and become final.
>>
>>My 2 cents - based on 30 years of building document retrieval database for
>>litigation support.
>>
>>Jim Keane
>>Vice Chair, LegalXML Member Section Steering Committee
>>Co-Chair, OdrXML
>>
>>cc: Ad hoc group from LegalXML considering normalization of our document
>>collection
>>    	Professor Lawrence Leff (who has offered to assist with document
>>classification)
>>    	Robin Gibson, Legal XML CourtFiling
>>    	Rogers Winters, Legal XML CourtFiling
>>
>>James I. Keane
>>JKeane.Law.Pro
>>20 Esworthy Terrace
>>North Potomac MD 20878
>>301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
>>www.jkeane.com <http://www.jkeane.com>
>>
>>Co-Author and Annual Update Editor of Treatise: Litigation Support Systems,
>>An Attorney Guide 2nd
>><http://www.westgroup.com/store/product.asp?product_id=16989703&catalog_name
>>=wgstore>   Ed. (WestGroup, 1992, updated through 2002)
>>
>>
>>-----Original Message-----
>>From: Daniel Greenwood [mailto:dang@mit.edu]
>>Sent: Monday, January 06, 2003 12:33 PM
>>To: Eve L. Maler; chairs@lists.oasis-open.org
>>Subject: RE: [chairs] Oasis document identifiers - conclusion?
>>
>>
>>Eve and fellow Chairs,
>>
>>I like and support the second suggestion
>>[TC-Phase-StandardName-Version], and I agree that it is worth
>>designating a Committee Specification [cs] differently from a draft or
>>an Oasis Standard [os] because under OASIS rules, a Committee
>>Specification is a special and recognized official plateau and in many
>>cases constitutes the final phase of formalization.
>>
>>Thanks,
>> - Daniel Greenwood, Chair of the eContracts TC and member of the
>>OASIS/LegalXML Member Section Steering Committee
>>
>>==============================================
>>|  Daniel J. Greenwood, Esq.
>>|  Director, E-Commerce Architecture Program
>>|  MIT School of Architecture and Planning
>>|  77 Massachusetts Avenue, Room 7-231
>>|  Cambridge, MA 02139
>>|     http://ecitizen.mit.edu
>>|     or http://www.civics.com
>>|     Mobile: 617-851-0412
>>|     Desk: 617-868-1746
>>|     dang@mit.edu
>>==============================================
>>
>>-----Original Message-----
>>From: Eve L. Maler [mailto:eve.maler@sun.com]
>>Sent: Monday, January 06, 2003 11:39 AM
>>To: chairs@lists.oasis-open.org
>>Subject: Re: [chairs] Oasis document identifiers - conclusion?
>>
>>As far as I know these files will never be in the same area, but
>>general-to-specific is pretty much my reasoning for preferring the
>>latter...  Does anyone *disagree* with the second style shown below?
>>
>>        Eve
>>
>>Drummond Reed wrote:
>> > Is this preferable?
>>  
>>
>>>   draft-saml-bindings-05
>>>   draft-saml-bindings-06
>>>   cs-saml-bindings-01
>>>
>>>Or is this?
>>>
>>>   saml-draft-bindings-05
>>>   saml-draft-bindings-06
>>>   saml-cs-bindings-01
>>>
>>>Drummond replies:
>>>
>>>Classic database sorting decision. The latter makes the most sense.
>>>    
>>
>>Imagine
>>  
>>
>>>searching long lists of TC docs from many TCs. To have them grouped
>>>    
>>
>>by TC
>>  
>>
>>>seems a lot more intuitive than by status.
>>>    
>>
>>--
>>Eve Maler                                        +1 781 442 3190
>>Sun Microsystems                            cell +1 781 354 9441
>>Web Technologies and Standards               eve.maler @ sun.com
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>  
> 
> 


-- 
=================================================================
Karl F. Best
Vice President, OASIS
+1 978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org