RE: External Classification Scheme -- Meeting Report

[Len Gallagher <LGallagher@nist.gov>]

Kathryn,

It is NOT proposed that the classifier (i.e. the one who uses a 
classification scheme to classify an object) would have to parse the path 
for that node.  For example, the classifier could say that a book is 
classified by "TA357.5" without having to break the code up into 3 pieces 
for its 3 inferred levels.

More comments in-line below.

-- Len



At 12:35 PM 9/18/01, Breininger, Kathryn R wrote:
>Len, I consulted with two colleagues on these issues, and I don't think I am
>entirely clear yet on all aspects of the proposals.  Here are some general
>comments (with input from two very talented colleagues!)
>
>I am trying to make sure I understand exactly what is proposed, so have
>tried to write my questions and understanding in very simple vocabulary.
>The following makes sense (our understanding derived from the Sept 6th
>e-mail, subject - Implicit Library Classification Schemes, see below)
>
>1. A site exists that contains the entire Library of Congress classification
>schedule.


Yes -- this is the underlying assumption. And that site may NOT be a 
conforming ebXML Registry site so it may not be possible to send a message 
to that site to get back an ebXML coded representation of the entire 
classification scheme.


>2. This entire site will be URLreferenced in an electronic repository for
>use in assigning classification numbers to electronic resources.
>(urn:nist-gov:cs:libv001)


Yes again -- but note that in the example below I assumed that the library 
classification scheme was an instance of "ExtrinsicObject".  Thus I used 
the contentURI attribute to hold the URL for the site that contains the 
entire Library of Congress classification schedule.  This is an issue 
because, currently, the ClassificationScheme class does not have that 
attribute. If contentURI were an attribute of the RegistryEntry class, 
thereby allowing any RegistryEntry to reference an external repository 
item, we wouldn't have this problem.


>3.  The query outlined in Len's Question 4 - searching on the 'QA' - should
>return Mathematics and Computer science books.


Yes -- the intent is that ALL nodes that have paths that begin a certain 
way are included. It gets more complicated for classification schemes that 
do not have the "path" embedded in the "code" for each node. For example, 
in a multi-level geography classification scheme, the predicate:

     Path BEGINSWITH "Asia"

should test true for a node with code="Japan", because the implied path for 
Japan is "Asia/Japan".

We have a getPath() method identified in ebRIM, but there are no rules for 
exactly what it returns. We really need such rules before users can start 
treating path as an attribute.


>In reference to the formulations in Len's question 2 of the subject e-mail
>(below), does this mean that a code instance is submitted with a null id -


The only reason the id is null in the example is because, currently, it is 
a required attribute of the Classification class. I think it should not be 
required, since we have enough information in other attributes.


>in other words, is there an attempt to develop an outline of the LC
>classification numbers that exist with no reference to the works that are so
>classified?  In other words,  is it proposed to recreate the entire LC
>classification with nulls?


NO -- that is not the intention. Only a single classification instance need 
be supplied for each book to be registered, e.g. 
path="TA357.5".  Optionally, we might allow the classifier to provide the 
complete path as 3 separate levels, e.g. {(1,TA), (2,357), (3,5)}, but I 
don't think that should ever be required. In the library classification 
scheme example, it is well understood that "TA357.5" represents the entire 
path.


>Perhaps I am misunderstanding here, but it seems
>if there is an existing classification in an electronic format for
>referencing, what is the purpose in recreating it in its entirety in each
>registry that wants to use that particular classification schedule when
>there may not be objects associated with some of the pieces of the
>classification scheme?

I agree. There should be no attempt to re-create the entire structure of 
the scheme.


>It does make sense to be able to query on the
>classification codes associated with the items in a particular registry (as
>illustrated above), but in this case the only classifications in the
>registry would be those that had associations with actual items registered.


I agree.


>Am I mis-understanding something here?


I think the only misunderstanding was to read more than was intended into 
assigning null values to required attributes that weren't being used for 
anything. I hope that's sufficient reason to make them not required. In my 
example, I was mis-using ClassificationNode because Classification did not 
have the needed flexibility to accommodate external classifications. I 
think we should fix this in the SubmitObjects XML and allow a 
Classification submittal to provide a "path" instead of forcing a contrived 
link to ClassificationNode.


>Len's e-mail:
>External Classification folks,
>
>Here's another use case that I think should be supported by whatever method
>we choose for identifying and using external classification schemes.
>
>Copied below are examples of Library Classifications as used by the NIST
>library. The first line of each entry is a combination of "classification
>by subject" and "date" and "unique identifier".
>
>--------------------------------------------------------------
>TA357.5 .V56 P69 1991
>Boundary integral and singularity methods for linearized viscous flow / C.
>Pozrikidis.
>
>QA484 .A7513 2001 CD-ROM
>Pi-unleashed / Jorg Arndt, Christoph Haenel ; translated from the German by
>Catriona and David Lischka.
>
>QA911 .P65 1997
>Introduction to theoretical and computational fluid dynamics / C.
>Pozrikidis.
>
>QA484 .A7513 2001
>Pi-unleashed / Jorg Arndt, Christoph Haenel ; translated from the German by
>Catriona and David Lischka.
>
>QA445 .C36 2001
>A course in modern geometries / Judith N. Cederberg.
>
>TJ1075 .S348 2001
>Biological micro- and nanotribology : nature's solutions/ Matthias Scherge,
>Stanislav N. Gorb.
>----------------------------------------------------------------
>
>Suppose that the characters from the beginning of the first line to the
>first blank space in the first line are a classification scheme for items
>that the NIST library wishes to register in some ebXML conforming Registry.
>The NIST library has a URL that points to a home page somewhere on the web
>that explains the meaning of the first 2 characters of the classification
>scheme and, separately, the meaning of the subsequent numeric digits before
>the first period, and separately, the meaning of any digits after the first
>period and before any blank spaces. The URL is
>
>     http://www.goodexplanations.com     -- I just made this up!
>
>Suppose everyone agrees that the "goodexplantions" site does a fine job of
>explaining the library classification scheme, but that the explicit nodes
>of the scheme do NOT exist in any ebXML conforming Registry. The NIST
>Library would still like to register its books in a conforming ebXML
>Registry and classify those books by this well-understood classification
>scheme.
>
>How should the NIST Library proceed?
>
>Let's agree that "goodexplantions" has done a wonderful job of defining
>this 3-level classification scheme and that everyone who visits the site
>comes away knowing that a string like "TA357.5" should be parsed as "TA"
>for level 1, "357" for level 2, and "5" for level 3. Everyone agrees that
>"TA357.5" is the proper string to use for representing those three levels.
>In effect the 3 levels will always be concatenated into a simple string.
>
>QUESTION-1: Will our specification support the NIST Library's attempted
>registration of the library classification scheme with the ebXML conforming
>Registry R as follows:
>
>     NIST submits a new ExtrinsicObject instance to R with
>       name = "urn:nist-gov:cs:libv001"
>       description = "A complete explanation of the NIST Library
>Classification Scheme"
>       objectType = "ClassificationScheme"
>       userVersion = "2001"
>       stability = "DynamicCompatible"
>       expirationDate = "2002-09-06"
>       contentURI = "http://www.goodexplanations.com"
>
>
>QUESTION-2: Given that the registration of the classification scheme is
>successful, will our specification support the NIST Library's attempted
>registration and Classification of the 6 books as follows:
>
>     NIST submits a new ExtrinsicObject instance to R with
>        name = "Boundary integral and singularity methods for
>linearized  viscous flow"
>        description = "A classic text by a famous author"
>        objectType = "OnLineBook"
>        contentURI = "ftp://library.nist.gov/book/TA357.5/V56/P69/1991"
>
>     In the same XML document as the above NIST submits a Classification
>instance
>        id = null
>        name = "urn:nist-gov:cs:libv001"
>        classifiedObject = IDREF to the above item
>        classificationNode = IDREF to the below item
>
>     In the same XML document as the above NIST submits a ClassificationNode
>instance
>        id = null
>        name = null
>        parent = null
>        code = "TA357.5"
>
>     The other 5 books below are registered in the same manner
>
>
>QUESTION-3: In the above QUESTION-2, would it make sense to define some
>nested XML submissions so clients wouldn't have to construct superfluous
>IDREF's?
>
>
>QUESTION-4: Assuming that the Registry R accepts the registration of the 6
>books, will the following query return the RegistryEntry identifiers for
>the 4 "Mathematics/ComputerScience" books, i.e. the "QA" books, listed
>below?
>
>    <RegistryEntryQuery>
>       <HasClassificationBranch>
>           <ClassificationFilter>
>               name EQUAL "urn:nist-gov:cs:libv001"     -- put into Clause
>syntax
>           </ClassificationFilter>
>           <ClassificationNodeFilter>
>               path STARTSWITH "QA"                     -- put into Clause
>syntax
>           </ClassificationNodeFilter>
>       </HasClassificationBranch>
>    </RegistryEentryQuery>
>
>NOTE: There is some subtle interplay between the "path" and "code"
>attributes in ClassificationNode and the "name" attribute in Classification
>and RegistryEntry. Our specification is currently silent on this interplay.
>We need more semantic rules!!
>
>Regards,
>Len
>
> > ----------
> > From:         Len Gallagher[SMTP:LGallagher@nist.gov]
> > Sent:         Thursday, September 13, 2001 2:37 PM
> > To:   OASIS ebXML Registry Ext Scheme
> > Subject:      External Classification Scheme -- Meeting Report
> >
> >
> > External Classification Team,
> >
> > Our September 13 teleconference was attended by three people:
> >
> >    Len Gallagher
> >    Nikola Stojanovic
> >    Farrukh Najmi
> >
> > We discussed the differing proposals by Len and Farrukh to treat
> > ExternalClassification as a subclass of Classification, or implicitly, to
> > treat Classification as a superclass of both InternalClassification and
> > ExternalClassification. The team is very close to agreement on RIM changes
> >
> > needed to accommodate a common interpretation of both types of
> > classifications.
> >
> > There are still some differences on whether Classification instances must
> > be supported in Registry Services for all RegistryObject subclasses, or
> > just some subset of them, in particular RegistryEntry and possibly
> > Organization.
> >
> > It would be helpful if other team members commented on the proposals.
> >
> > -- Len
> >
> >
> > **************************************************************
> > Len Gallagher                             LGallagher@nist.gov
> > NIST                                      Work: 301-975-3251
> > Bldg 820  Room 562                        Home: 301-424-1928
> > Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
> > **************************************************************
> >
> >
> > ----------------------------------------------------------------
> > 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>

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************