Re: automatic web service discovery?

Davy Vermeir wrote:
> Hello,
> 
> I'm a student at the VUB doing an apprenticeship on Semantic Web Services
> at the SSEL-lab at the VUB.
> While performing a survey on some approaches on how to describe Web
> Services in a semantic way, i found the DAML-s approach, but I still have
> some things in mind that are not very clear to me.
> 
> In the documents I found on DAML-s on the website, a Web Service can be
> described based on the IOPE's, and they claim that this is enough for
> automatic web service discovery.

Although, the profile of the service was intended for discovery, it is 
by no means sufficient. The Discovery and Match-making mechanism will 
have to look at the processModel also. The DAML-S specs make a mention 
of this in one of the documents. In your example, you have just shown 
the profile which is clearly not enough for Discovery and Match-making.

> Since "EFFECTS" here are described as physical effects, I don't understand 
> how these IOPE's can fully describe a web service for automatic discovery.
> 
> An example to make it clearer:
> A Concrete Service A implementing an operation to look for all available
> rooms in a hotel.
> 
> <profile:input>
>   <profile:ParameterDescription rdf:ID="availableHotelRoomsInput">
>   <profile:parameterName>availableHotelRoomsInput</profile:parameterName>
>     <profile:restrictedTo
> rdf:resource="http://exampleontology#Hotel">
>     <profile:refersTo rdf:resource="http://notimportant">
>   </profile:ParameterDescription>
> </profile:input>
> 
> <profile:output>
>   <profile:ParameterDescription rdf:ID="availableHotelRoomsOutput">
>   <profile:parameterName>AvailableHotelRoomsOutput</profile:parameterName>
>     <profile:restrictedTo
> rdf:resource="http://exampleontology#listOfRooms">
>     <profile:refersTo rdf:resource="http://notimportant">
>   </profile:ParameterDescription>
> </profile:output>
> 
> A Conrete Service B that implements an operation to look for all rooms in
> a hotel that have a minimum amount of quality
> 
> <profile:input>
>   <profile:ParameterDescription rdf:ID="qualityHotelRoomsInput">
>     <profile:parameterName>qualityHotelRoomsInput</profile:parameterName>
>     <profile:restrictedTo
> rdf:resource="http://exampleontology#Hotel">
>     <profile:refersTo rdf:resource="http://notimportant">
>   </profile:ParameterDescription>
> </profile:input>
> 
> <profile:output>
>   <profile:ParameterDescription rdf:ID="qualityHotelRoomsOutput">
>     <profile:parameterName>qualityHotelRoomsOutput</profile:parameterName>
>     <profile:restrictedTo
> rdf:resource="http://exampleontology#listOfRooms">
>     <profile:refersTo rdf:resource="http://notimportant">
>   </profile:ParameterDescription>
> </profile:output>
> 
> As you can see, both these services share the same semantic descriptions
> of the inputs and outputs of their operation. The inputs map to the
> "Hotel" - concept in the ontology , while the outputs map to the
> "listOfRooms" - concept.
> The operations implemented by these services have no preconditions or
> effects (since the retrieval of information has no physical effect).
> 
> Problem:
> If a client would have a request for a service that has a "Hotel" as an
> input and a "listOfRooms" as an output both of these service could be
> returned as a match, while the operations implemented by these services
> have a totally different meaning(one is for lookin up available rooms and
> the other is for looking up rooms that have a certain amount of quality).

I think to solve this problem we should look at the way documentation of 
APIs are published (example-Java docs). You choose to use a specific 
method based on primarily 5 criteria. The package, the class, the method 
name, input arguments and the return type. In Java, the combination of 
these parameters uniquely identify the method. The Java compiler ensures 
this. But, when you are describing services, you are free to describe 
anything. At the moment, it is the publisher who should ensure that the 
services she/he publishes can be easily differentiated.

mithun
http://www.cs.umbc.edu/~mits1

> 
> Is there a way to solve this in DAML-S? 
> 
> Greetings,
> 
> Davy Vermeir
> 
> 
> 
>

Received on Friday, 24 October 2003 08:22:59 UTC