[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