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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-dev message

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


Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons


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
begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG
version:2.1
end:vcard



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