Re: Using Classifications in Filter Queries

[Len Gallagher <LGallagher@nist.gov>]

Query team,

During our teleconference today I made reference to the desirability of 
having a new method defined for ClassificationNode, i.e. getPathElements(), 
that would return a collection of ordered pairs to identify each node 
explicitly in the "path" hierarchy of a given node.

The use case in support of that position was distributed to this list on 
9/19/01 and is copied below.

Farrukh volunteered to describe how XPATH syntax could be used instead of 
the PathElement collection I describe in order to achieve the same results 
for queries over Classifications and for submission of Classification 
instances. I'm sure he will be successful, but that doesn't contradict my 
claim that adding this proposed new method to RIM would be very valuable 
for some users like me who'd prefer not to have to learn XPATH syntax 
before being able to query the Registry.

-- Len


At 05:48 PM 9/19/01, Len Gallagher wrote:

>Query Team,
>
>Early in Query team discussions, there was discussion of using XPATH as 
>the required syntax for referencing the path hierarchy of a node in a 
>classification scheme. I have no objection to that -- but since I'm not 
>familiar with XPATH syntax I'd like to be assured that a more familiar 
>method for referencing a node's path hierarchy is also available to me.
>
>I'd like the team to consider the following use case for a classification 
>scheme and how nodes of that scheme might be referenced as part of a 
>Registry Query over Classification or ClassificationNode instances or as 
>part of a Classification submittal:
>
>Let A, B, and C be three desired criteria for a LearningObject (LO). 
>Suppose I want to register LO's (e.g. Online courses) in our Registry.  In 
>addition, suppose I want to classify my learning objects by the priorities 
>in which the criteria are addressed. For example, the classification path 
>will be "C/B" if C is addressed as a first priority and B is addressed as 
>a second priority.
>
>I could define a 2-level classification scheme as follows to identify all 
>of the possibilities:
>
>      None       -- Meaning none of the criteria are addressed.
>      A          -- Meaning A is addressed
>        B        -- Meaning A is Primary and B is Secondary
>        C        -- Meaning A is Primary and C is Secondary
>      B          -- Meaning B is addressed
>        A        -- Meaning B is Primary and A is Secondary
>        C        -- Meaning B is Primary and C is Secondary
>      C          -- Meaning C is addressed
>        A        -- Meaning C is Primary and A is Secondary
>        B        -- Meaning C is Primary and B is Secondary
>
>This classification scheme has 10 nodes arranged in 2 levels, with 4 nodes 
>at the first level (called Primary) and 6 nodes at the second level 
>(called Secondary).
>
>Suppose getPathElements() is a method defined on ClassificationNode, and 
>suppose that it returns a collection of elements as follows:
>
>   None.getPathElements()   returns   { (Primary,None) }
>   A.getPathElements()      returns   { (Primary,A) }
>   A/B.getPathElements()    returns   { (Primary,A), (Secondary,B) }
>   A/C.getPathElements()    returns   { (Primary,A), (Secondary,C) }
>   B.getPathElements()      returns   { (Primary,B) }
>   B/A.getPathElements()    returns   { (Primary,B), (Secondary,A) }
>   B/C.getPathElements()    returns   { (Primary,B), (Secondary,C) }
>   C.getPathElements()      returns   { (Primary,C) }
>   C/A.getPathElements()    returns   { (Primary,C), (Secondary,A) }
>   C/B.getPathElements()    returns   { (Primary,C), (Secondary,B) }
>
>The assumption here is that the definer of the of the classification 
>scheme would also be allowed, as an option, to specify semantic names for 
>the levels of the scheme and that those level names would identify the 
>level attribute of the result set returned from getPathElements(). In the 
>absence of level names, levels would be 1, 2, 3, ...
>
>Then the result of the getPathElements() method could be interpreted as a 
>collection of instances of a class, PathElement, having attributes "level" 
>and "value", where each instance of the class is implicitly connected to 
>the node from which it was derived. Without having to learn any special 
>XPATH syntax, and without having to extend our Clause syntax, a user could 
>assume the existence of these derived instances of PathElement and issue 
>queries with the following predicates:
>
>  level="Primary" AND value="None"   -- to see which LO's satisfy no criteria
>  value="B"                          -- to see which LO's address criteria B
>  level="Primary" AND value="C"      -- to see which LO's address C as 
> Primary criteria
>  level="Secondary" AND value="A"    -- to see which LO's address A as 
> Secondary criteria
>  level="Primary"
>     AND (value="A" OR value = "C")  -- to see which LO's treat A or C as 
> Primary criteria
>
>More complex expressions are possible using multiple PathElementFilter's 
>in FilterQuery syntax.
>
>CONCLUSION
>
>I'm not a user of XPATH so I don't know if XPATH syntax can easily address 
>these requirements for querying named levels of a classification scheme 
>individually. But asking implementors to implement the getPathElements() 
>method on the ClassificationNode class would be any easy way to provide 
>needed functionality without having to require the use of XPATH syntax in 
>a query.
>
>I don't know how XPATH syntax would work on a Classification submittal. 
>But it would certainly be easy to extend the XML element for 
>Classification submittal to something like the following:
>
>   <!ELEMENT Classification
>     ( ...,
>       PathElement*  )>
>
>   <!ELEMENT PathElement EMPTY >
>   <!ATTLIST PathElement
>        level   CDATA    IMPLIED
>        value   CDATA    REQUIRED >
>
>Then it would be easy to submit any of the (level,value) pairs described 
>above as a specification of the node intended to be referenced by that 
>Classification instance.
>
>-- 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>

**************************************************************
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
**************************************************************