[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [chairs] Oasis document identifiers - conclusion?
Jim, Your 30 years of experience building document retrieval databases for litigation support really shows. I like this format very much. =Drummond -----Original Message----- From: jkeane [mailto:firstname.lastname@example.org] Sent: Friday, January 10, 2003 7:23 AM To: email@example.com Cc: firstname.lastname@example.org Subject: RE: [chairs] Oasis document identifiers - conclusion? 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:email@example.com] Sent: Thursday, January 09, 2003 3:58 PM Cc: firstname.lastname@example.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:email@example.com] > Sent: Monday, January 06, 2003 1:42 PM > To: firstname.lastname@example.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:email@example.com] >>Sent: Monday, January 06, 2003 12:33 PM >>To: Eve L. Maler; firstname.lastname@example.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 >>| email@example.com >>============================================== >> >>-----Original Message----- >>From: Eve L. Maler [mailto:firstname.lastname@example.org] >>Sent: Monday, January 06, 2003 11:39 AM >>To: email@example.com >>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 firstname.lastname@example.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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC