OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Using Classifications in Filter Queries



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().

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC