Paul Denning wrote:
> At 10:54 AM 2005-06-22, Farrukh Najmi wrote:
>
>> As far as I know, adding new taxonomies (complete with taxonomy
>> values) is quite vendor specific in UDDI 3. Also there is no standard
>> way to extend values for standard/checked taxonomies for domain
>> specific profiles.
>
>
> Adding a taxonomy (without its taxons or value-set) is very common in
> UDDI. Simply create a tModel and put the following in its categoryBag
ebXML Registry supports both taxonomies that have values defined and
checked and those that do not.
My exprience in working with many registry deployments is that in most
cases one wants taxonomy values to be defined.
These values serve as domain for controlling data entry in UIs (e.g. A
Gender taxonomy with values Male, Female and Other).
These values also enable the user of the UI to not have to know the
allowed values.
Taxonomies without values make sense typically as a namespace where the
choices are unlimited (e.g. National ID #).
>
> <categoryBag>
> <keyedReference tModelKey="uddi:uddi.org:categorization:types"
> keyName="Categorization system" keyValue="categorization"/>
> </categoryBag>
>
> Having this in the categoryBag makes the a "taxonomy tModel".
>
> (This is UDDI v3, but there is also a v2 tModelKey.)
>
> As far as extending the values, this would be something that would be
> done as a technical note or best practice, similar to the profiles for
> ebXML Registry.
User defined taxonomies complete with valuesets is a standard part of
ebXML Registry and has been seen version 1.0. No tech note is needed for
that.
>
> Although it is often stated that taxonomies lack semantics, it only
> lacks them in terms of a syntax for expressing the semantics.
> Certainly there is a meaning for each taxon of a taxonomy. For
> example, NAICS code 111110 is understood to mean Soybean Farming.
ebXML Registry taxonomies support OO inheritence semantic.
For example, you MAY have a geography taxonomy with hierarchical values
like:
Asia
Japan
Tokyo
Korea
If an object is classified (catgeorized in UDDI speak) by Japan or Tokyo
geography it will be matched
by a search for objects classified by Asia Geography.
>
> Maybe you want to extend the Soybean Farming branch of NAICS with your
> own taxonomy; perhaps there are different types of soybeans (go with
> me here ;-)
> Perhaps "American Soybean Farming" and "Asian Soybean Farming".
>
> You could create a tModel for this new taxonomy. Its categoryBag
> would look like this
>
> <categoryBag>
> <keyedReference tModelKey="uddi:uddi.org:categorization:types"
> keyName="Categorization system" keyValue="categorization"/>
> <keyedReference tModeKey="uddi:uddi.org:ubr:taxonomy:naics"
> keyName="Soybean Farming" keyValue="111110"/>
> </categoryBag>
>
> If you have a business that you want to categorize as "American
> Soybean Farming", you would use the new taxonomy in its categoryBag.
> You could also use the NAICS 111110 in it categoryBag. There is an
> implied "is a" relationship between the business and its categoryBag.
> This business is an American Soybean Farming business. It is also a
> Soybean Farming business.
>
> This would be one way to extend NAICS in UDDI. There may be other ways.
>
> The people using the taxonomies would understand the semantics, even
> though all that is put in UDDI is a keyValue.
>
> The philosphy was to keep UDDI simple and extensible. Similar to the
> philosphy around SOAP: keep it simple and provide well understood
> mechanisms for extending it (e.g., SOAP headers).
I am not convinced that above is either simple or extensible but I will
not belabor that point.
ebXML Registry philosophy is "generic and extensible" and "reusing a few
good primitives" over and over to solve diverse problems.
As for simplicity we aim to be as simple as possible but not at teh
expense of limiting our core architecture.
>
> I need to research how ebRIM/ebRS specify how to extend values for a
> standard/checked taxonomy.
Thanks! I will be glad to answer any questions you may have after your
reading.
>
> Anyway, taxonomies are old news; give me folksonomy!!!
> http://en.wikipedia.org/wiki/Folksonomy
Interesting link. Thanks for sharing.
I see ontologies as playing a bigger role in the future of Federated
Information Management.
That is the focus of the Semantic Content Management SC of ebXML
Registry TC that I co-chair.
Thanks again for the stimulating discussion.
--
Regards,
Farrukh Najmi
Editor: ebXML Registry TC
Co-chair: Semantic Content Management SC of OASIS ebXML Registry TC
Co-chair: Registry SC of OASIS egov TC
Lead Architect: freebXML Registry open source project (
http://ebxmlrr.sourceforge.net )
Spec Lead: JAXR API
Federated Information Management Architect: Sun Microsystems
