RE: [chairs] Oasis document identifiers - conclusion?

[jkeane <jik@jkeane.com>]

Here is a link to the Kavi document repository on their public web site.

http://www.kavi.com/prodserv/groups/page_two/

Can we get a Kavi person in this discussion?

Re file names: I've been working with virtual teams since 1985, and have
some thoughts on shared file naming conventions.

1)  Have a meaningful name - no acronyms or abbreviations for contents.
Short TC names do makes sense.  I keep an archive of work products, pruning
out unnecessary documents and most drafts after the project is long over.
When you are browsing an older directory the Alzheimer effect kicks in after
six months.

2)  We store related documents in project sub-directories.  This makes it
unnecessary to include extensive generic info in every file name.  If you
store all the docs in a single directory, it would make more sense to have
the prime sort by TC name.

3) Include the date (as proposed, but in a sortable format)  File dates
change (i.e. moving all files from computer A to computer B for maintenance.

4) Include version sequence in sortable format.  This will avoid confusion
about which drafts are on the table.

5) Add any relevant trailing info about status or special features.


Here is an example of what we used in drafting the Online Dispute Resolution
Charter. This approach has enabled me to work with ad hoc teams over many
projects over many years and not have too much confusion or spending time in
discussions (which we needed do here) like this.

OdrXML Charter 1.0 DRAFT 2002.09.26.doc
OdrXML Charter 1.1 DRAFT 2002.10.07.doc
OdrXML Charter 1.2 DRAFT FINAL 2002.10.18.doc
OdrXML Charter 1.2 DRAFT FINAL REDLINE 2002.10.18.doc
OdrXML Charter 1.2a DRAFT FINAL 2002.10.19.doc
OdrXML Charter FINAL 2002.11.11.doc

   That's what I used in my directory. We used the redline indicator to show
a version highlighting the substantive changes.  We use 1.2a to reflect some
minor changes from proof reading the penultimate draft. The actual final
document appears in html text on the web page.

When appropriate we have also added author initials, particularly on drafts
that occur in one day or it is important to reflect the position of
significant interests, as in successive contract drafts. That is probably
not as important here.

We also try to use the metadata in the document profiles.  It would be great
to have the metadata and file naming elements work in tandem through XML.

There is inherent arbitrariness in all file naming conventions. I humbly
offer this method as an example of what has worked in many groups over many
years across multiple systems in multiple law firms in the middle of
contract negotiations and contested law suits among very picky lawyers.

This approach sorts itself a useful order, and follows the legal precept of
"res ipsa loquitur" or "The thing speaks for itself."

I do urge creating the metadata, tags or fields in a database that can
generate suitable bibliographic postings rather than creating a highly
stylized bibliography in Word. There is great librarian type software that
can do this on the fly. See, e.g. Inmagic dbTextWorks.

The database should also allow queries and ad hoc reports with further data
such as URL, status, sub-committee, author, author organizations -- as
previously suggested.

My 2 cents.

Happy new year to all...

Jim Keane
Vice Chair Legal XML Member Section
Co-Chair OdrXML Technical Committee


James I. Keane
JKeane.Law.Pro
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: Karl Best [mailto:karl.best@oasis-open.org]
Sent: Thursday, January 09, 2003 3:58 PM
Cc: chairs@lists.oasis-open.org
Subject: Re: [chairs] Oasis document identifiers - conclusion?


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_na
me
>>=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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>