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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-ex-scheme message

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


Subject: Classification Query Use Case



External Classifications folks,

Below I present a Registry use case and follow it with a question as to 
whether it's assumptions should be supported by our specifications.

Let R1 and R2 be conforming ebXML Registries. Assume that R1 and R2 were 
set up independently and that they are NOT federated in any formal sense of 
the word.

Let C be a client that wishes to communicate with both R1 and R2.

Suppose the North American Industry Classification Scheme (NAICS) is 
"internal" to R1 and "external" to R2. For now, assume that "internal" and 
"external" mean the following:

* NAICS being internal to R1 means that R1 has a RegistryEntry instance, 
call it RE1, that carries the metadata for NAICS. In addition, R1 contains 
all of the ClassificationNode instances for NAICS.

* NAICS being external to R2 means that R2 has a RegistryEntry instance, 
call it RE2, that also carries metadata for NAICS, but not its node 
instances. In addition, RE2 points to RE1 in R1 as the holder of all of the 
specific node details. For now, also assume that one of the requirements of 
pointing to an external item is that the pointing Registry (i.e. R2) use 
the same URN to identify that item as does the Registry being pointed to 
(i.e. R1).

Assume that R1 and R2 both hold a number of repository items that have been 
classified by NAICS. Also assume that both R1 and R2 use the following URN 
to identify NAICS: "urn:ntis-gov:naics:1997". The client C desires to 
submit a query to R1 and R2 to identify all repository items in either 
Repository that have been classified by node "33611", i.e. "Automobile and 
Light Duty Motor Vehicle Manufacturing".

QUESTION: Shouldn't C be able to submit the same RegistryEntryQuery to both 
R1 and R2 to identify the repository items in each Registry that have been 
classified by the "33611" node?

In particular, shouldn't a Query like the following (cf Section 8.2.2 of 
ebRS) be executable at both locations?

   <RegistryEntryQuery>
      <HasClassificationBranch>
          <ClassificationFilter>
              name EQUAL "urn:ntis-gov:naics:1997"
          </ClassificationFilter>
          <ClassificationNodeFilter>
              path EQUAL "33611"
          </ClassificationNodeFilter>
      </HasClassificationBranch>
   </RegistryEentryQuery>

The advantage of a Query like this one is that the client C need not know 
whether NAICS is "internal" or "external" to R1 or R2. The Query syntax is 
identical in both cases. The only difference is that R1 can check 
immediately to see if the "path" is well defined in NAICS, whereas R2 could 
not do so easily without submitting a separate query to R1.

QUERY ASSUMPTIONS

I've made some assumptions in the above query that are not explicitly 
enforced by ebRIM or ebRS. They include:

1) That the "name" attribute of Classification is a URN that uniquely 
identifies the RegistryEntry instance of exactly one ClassificationScheme.

2) That the "path" attribute of ClassificationNode is a simple value, when 
in general it may be a sequence of values, e.g. "geography/japan", or even 
a named sequence of values, e.g. Genus="Homo" and Species="sapien". We 
should be able to handle complex path declarations in an identical manner 
for both "internal" and "external" classification schemes.

Regards,
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