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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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]