RE: [uddi-spec] Fw: DAML-S and UDDI

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

Anne,

I just replied to Jeff's mail (see attachment).

Thanks,
 Claus

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net] 
Sent: Dienstag, 5. August 2003 19:42
To: Uddi-Spec
Subject: [uddi-spec] Fw: DAML-S and UDDI



----- Original Message -----
From: "Jeff Lansing" <jeff@polexis.com>
To: <www-ws@w3c.org>
Sent: Tuesday, August 05, 2003 1:23 PM
Subject: DAML-S and UDDI


>
> "Delivering Semantic Web Services" [1] presents the problem of
> distinguishing a US-based service for weather data from a service for
> US-area weather data:
>
> "The problem of UDDI is that it does not have an explicit representation
> of what the Web Service does. Therefore, the search for a Web Service
> with a given capability becomes very difficult. As an example, to locate
> a Web Service that reports weather information within the US, a
> requester may look for all the Web Services that contain a TModel
> associated with a classification of services such as NAICS [18] which
> are specified as weather providers, and all the Web Services
> descriptions that contain a TModel that associate the Web Service with
> the US, and then look in the intersection of the results of the two
> searches. The problem of course is that this type of search cannot
> distinguish between weather services that provide information about the
> US, from US based weather services that may provide information about
> the weather in other countries. Overall, because UDDI misses any form of
> capability representation and capability matching, it is extremely
> difficult to find Web Services with a desired capability using UDDI."
>
> It is strongly suggested in [1] that DAML-S can solve this problem. It
> is perhaps even suggested (because [1] references [2]) that representing
> DAML-S profile information in UDDI is intimately involved in the way
> that DAML-S solves this problem. But in fact [1] does not actually say
> how to solve this problem. Is that because the solution is so obvious?
> Let's see.
>
> Obviously this problem could be solved if we could distinguish
> qualifiers on the service from qualifiers on the output of the service.
>
> One way to add qualifiers to a service in UDDI is to add keyedReferences
> to the CategoryBag of the service; these keyedReferences can then
> qualify the service by associating it with  "positions" in a
> classification. (So, e.g., this could qualify a service as a weather
> service.)
>
> In [2] it is suggested to add additional keyedReferences for the
> attributes in the DAML-S profile, to the CategoryBag of a service. For
> example:
>
> KeyedReference
>     KeyName= Output
>     KeyValue= phenomenologyOntology:weather
>     TModelKey= "UUID of the DAML-S Output TModel"
>
> might be added for the example. But this still doesn't solve the
> problem, because it doesn't actually qualify the output, as to its
> geographic region. So something is still missing.
>
> Perhaps the "DAML-S Output TModel" also needs to have keyedReferences
> that qualify it, in the way that a service does? Is that the solution?
>
> Jeff
>
>
> [1]
>
http://www.ri.cmu.edu/pub_files/pub4/paolucci_massimo_2003_1/paolucci_massim
o_2003_1.pdf
> [2] http://eprints.ecs.soton.ac.uk/archive/00007778/
>


You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php

---

• From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
• To: "'www-ws@w3.org'" <www-ws@w3.org>
• Date: Wed, 6 Aug 2003 09:26:42 +0200

Jeff,

While I am not familiar with DAML-S, I don't understand the problem statement "The problem of UDDI is that it does not have an explicit representation of what the Web Service does. Therefore, the search for a Web Service with a given capability becomes very difficult. [...]"
What prevents one's publishing separate tModels for the different meanings of, for example, geographical categorization? One tModel for the service location ("this service is located in the US" and one tModel for the service area ("this service can be used in the US") meets the given requirement.
UDDI V3 [1] also introduced the concept of derived value sets in order to link category systems that are based on the same set of values but with a different meaning.

Claus

[1] http://uddi.org/pubs/uddi-v3.00-published-20020719.htm#_Toc42047576 <http://uddi.org/pubs/uddi-v3.00-published-20020719.htm#_Toc42047576> 

---