Re: automatic web service discovery?

Davy,

thanks for the good question.  Your question has two answers:

1.  the outputs of the second examples are ill-defined ,  rather than 
say that the output is the number of rooms you should specify that the 
output is the number of rooms with a given quality.  To do this you 
should use the ontology that you have appropriately,  for example by 
creating a class of "quality" rooms that has a restriction on the 
quality level.

2.  In general,  the profile is just an approximation of the service 
description.  It is very well possible that different services have the 
same semantic description;  Ultimately,  this result depends on the 
level of abstraction of the two descriptions and how closely do they 
represent the service that they describe.  In your case, the second 
description is just an approximation of the function computed by the Web 
service.

Hope that this helps,

--- Massimo



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. 
>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).
>
>Is there a way to solve this in DAML-S? 
>
>Greetings,
>
>Davy Vermeir
>
>
>
>
>
>  
>

Received on Sunday, 26 October 2003 22:48:01 UTC