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: 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]
> [2] http://eprints.ecs.soton.ac.uk/archive/00007778/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]