[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons
We are all collectively going through a learning experience about both UDDI and ebXML Registry standard and this thread has been very valuable in exploring their design centers and use cases. More inline below... Farrukh Najmi wrote: > 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. On second thoughts my assertion above may seem to be just subjective opinion. I will attempt to clarify my assertion based on my understanding of the two standards (which may well be dated or flawed). -Does UDDI taxonomy support, described above, allow for a registered user of a UDDI registry to publish publish a brand new taxonomy complete with its taxonomy values where the values are hierarchical (not flat) -Does it allow the same user to extend existing taxonomies with additional values? -Does it check that a categoryBag is using a valid taxonomy value from this user defined taxonomy? -Can a UI tool use the user defined taxonomy instantly after publish to guide and enforce the correct use of taxonomy values during data entry? -Does it allow a UDDI client to examine taxonomy values for this use defined taxonomy? -Does it allow user defined taxonomies or taxonomy values to be accessed controlled based on Role and Identity? -Can changes made to user defined taxonomies be versioned? My understanding of UDDI 3.0 is that the answer to *ALL* of above is that NO it cannot be done in a manner supported by the standard. ebXML Registry has supported all of above use cases in a standard, interoperable, normative manner since version 1.0 several years ago. And it does all of above using the "few good primitives" principal that we believe is very important for a good extensible and robust architecture. > > 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 will illustrate above point with a concrete example. In UDDI's philosophy of simplicity it avoided a generic architecture. For example, there are multiple API calls for find and get (one for each Business, Service, BindingTemplate, Tmodel). In ebXML Registry first there is no distinction between find and get. Its one and the same thing. Next, there is only one API to find/get any type of object (even those user defined types not defined by spec e.g. "CookingRecipe"). Further that query API allows for a powerful ad hoc query capability that can be as simple or complex as your use case desire (e.g. Find All CookingRecipes that have ingredients "sugar" and "salt"). The complexity of the more complex queries is managed/hidden from the end user by storing them as "stored parameterized queries" within the registry. The client is exposed to a simple API (or GUI) which lets them specify parameters. Parameter entry can be guided and validated by hierarchical taxonomies. All of above may not be the simplest, but it is definitely very minimalistic, as simple as it can be using "a few good primitives" philosophy to deliver a "generic and extensible" and robust architecture that can meet many diverse needs as they become known. UDDI started out with a specific problem as its target: "Publish/discovery of businesses and services" ebXML Registry started out with the assumption that the problem domain is infinite and that we MUST design our architecture accordingly. This difference in the genesis of both specs shows over and over in every feature that both specs provide and in a nutshell if the difference between the two specs. -- 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 Coming to Java ONE 2005? If so checkout Sun's Service Registry at Booth #802 in the Java ONE Pavillion.
begin:vcard fn:Farrukh Najmi n:Najmi;Farrukh email;internet:email@example.com tel;work:781-442-9017 url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG version:2.1 end:vcard