[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Elements of a "Semantic UDDI" Solution
I am rather new to semantic networks, but having done some initial research I find it difficult to justify adding an rdfBag to UDDI entities. Perhaps further research and your comments will make me change my opinion, but I do not see how rdfBag facility adds value to a categoryBag for subsumption purposes. RDF statements are intended to establish predicate relationships between the subject (the resource being described) and various other objects. A similar capability already exists in UDDI and is represented by categoryBags. In UDDI terms, the subject is the entity containing a categoryBag, predicate is identified by a tModel and objects are identified by keyedReference keyValues, pointing to other entities inside or outside the registry as defined by the tModel. V3 isReplacedBy and owningBusiness tModels are examples of predicates establishing semantically significant relationships between subjects and objects that are all within the registry. Industry classification systems are an example of predicates establishing relationships between registry subjects and outside objects. Please correct me if my analogy is wrong or incomplete. Whether subsumption is desired by a registry inquirer can be conveyed either by the fashion in which the tModel (the one referred to in categoryBag) is described in the registry or by a new find qualifier, which enables or disables subsumption behavior. When subsumption is desired and the tModel has the necessary attributes that make it possible, it might work as follows. The registry contacts an outside inference engine to expand the query to cover more objects and possibly predicates (if it is aware of other taxonomies and is capable of reasoning across them). The generalized query is executed by the registry and its results (if any) are then filtered through the inference engine to exclude the irrelevant and less relevant matches. Ontology content is thus maintained entirely in the inference engine and is separate from UDDI information model. Whether we mandate support for certain ontology formats is a separate issue. Advantages of this approach are: - no/little client impact - backwards compatibility - flexible implementation (inference engine could be either built-in or external, could even be taxonomy provider's own) - guaranteed subsumption capability for V4 clients - keeps complexity low and non-UDDI-specific content out of the spec Limitations: - "indiscrete" :) (continuous) taxonomies not supported - range-based queries not supported - potentially high network bandwidth utilization I have a feeling that there are other functional limitations I am not aware of, because perhaps I do not see all the functions that are being requested as part of this semantic matching requirement. Daniel > -----Original Message----- > From: John Colgrave [mailto:colgrave@hursley.ibm.com] > Sent: Wednesday, December 10, 2003 2:39 PM > To: uddi-spec@lists.oasis-open.org > Subject: [uddi-spec] Elements of a "Semantic UDDI" Solution > > > Following on from yesterday's interesting discussion, I think > we need to consider the following elements when thinking > about extending UDDI with semantic matching capabilities: > 1) Service providers need to be able to use one or more > ontologies, written in one or more languages, to describe the > capabilities of their services. > 2) These ontologies need to be hosted somewhere and be > managed, discovered and used to validate uses of them as appropriate. > 3) Service providers need to be able to provide descriptions > of the capabilities of their service in one or more > languages, using these ontologies, and associate them with > the "traditional" UDDI model of the service. > 4) Service requesters need to be able to use one or more > ontologies, written in one or more languages, to describe > their requirements. > 5) Service requesters need to communicate their requirements > as part of a > (UDDI) query. > 6) Service requesters need to be able to control aspects of > the search, for example the strictness of matching to be > used, whether subsumption is allowed etc. > 7) Some kind of matching engine needs to match the > requester's requirements with service capabilities, in > conjunction with standard UDDI criteria (otherwise there is > no point in doing this in the context of UDDI). > > Most of the approaches I am familiar with have a very loose > coupling with UDDI and work with a standard UDDI registry, > providing all the integration either in the client or in a > separate service that provides a façade to UDDI, using a > non-standard interface. > > I understood Max to say that he thought that the ontologies > should be outside UDDI but the capability descriptions should > be inside UDDI, in this rdfBag, and the only validation to be > performed would be that the contents of the rdfBag matched > some RDF schema. On the requester side, I am not sure how > the requirements are represented or the details relating to > the query, although findQualifiers are the obvious approach > to the latter part. > > I think one of the major choices we need to make is to what > extent we want to bake something into the UDDI core as > opposed to allowing for external > (pluggable) components. > > John Colgrave > IBM > > > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members /leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]