RE: [uddi-spec] Elements of a "Semantic UDDI" Solution

["Ugo Corda" <UCorda@SeeBeyond.com>]

The fact that both service requesters and service providers might refer to multiple ontologies makes me wonder how much reasoning can be done across ontologies. I imagine some ontologies are so far apart (e.g. describing completely separate vertical industries) that reasoning across them would not make much sense. Other ontologies might be closer to each other, and including them in the same reasoning process could make more sense.

Does anybody know what is the current state of the art in cross-ontologies reasoning?

I think the resolution of this issue will affect what types of ontology-related queries we will allow and how we perform them. For instance, given an ontology-based query submitted by a service requester, we might need to screen the totality of ontologies referenced by a UDDI repository and identify only those service providers which refer to ontologies that are compatible with the service requester's ontologies.

Ugo

> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Wednesday, December 10, 2003 3:39 AM
> 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.