RE: Referencing multiple WSDL files using OWL-S

Hi Mithun

Thank you for your email. You are right I don't think I need to extend
the existing specs. I think I can use the secondary service grounding
that acts as an extension to the service interface. 

For example if a 'Picture Service' provided by a 'Mobile Phone', outputs
images of type 'GIF' and discovers a service called 'Visual Service'
provided by a 'Television', which takes as input an image of type 'JPEG'
- in this instance the two types are incompatible. This requires that we
determine if the two parameter types are conceptually the same. For
example if the parameter type for an input in the service request is
called 'GIF' and the parameter type for an Input Message in the WSDL
file is called 'JPEG', we can determine that these are conceptually
equivalent using a shared ontology. Once a conceptual relationship
between the two IOPEs has been found we can then try to discover an
intermediary service that takes as input a parameter of type 'GIF' and
generates an output of type 'JPEG'.

If we find, say a 'FormatConverterService', which can take as input a
'GIF' file and which produces a 'JPEG' file, we can define this as a
match and update the secondary service grounding with the information
regarding this service. I thought that the wsdlAtomicProcessGrounding
descriptions be used, but instead of forming explicit bindings to a WSDL
file, i.e. 

<grounding:portType>
	<xsd:anyURI rdf:value="&wsdl_file;#ConvertImage_PortType"/>
</grounding:portType>

We could have something like

<grounding:portType>
	<xsd:anyURI rdf:value="#ConvertImage_PortType"/>
</grounding:portType>

<portType name="ConvertImage_PortType>
	<operation name="ConvertImage">
		<input message="#ConvertImage_Input"/>
		<output message="ConvertImage_Output"/>
	</operation>
</portType>

In my research I am working with distributed ad hoc services that are
hosted in P2P networks, therefore I cannot explicitly bind to the WSDL
file of the services, because the hosting information will more than
likely change as devices connect and disconnect to different DNS servers
(as a result a different IP address with need to be used in the http
call as various times).

The way I can get around this is to use the 'wsdlDocument' element in
the extended service grounding for a particular 'atomicprocess' to
store, in this case the JXTA unique ID. For example

<grounding:wsdlDocument>
	Urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000010206
</grounding:wsdlDocument>

I am not sure if this makes sense, however I have played around with a
number of the OWL-S ontologies and a feel that the best way to extend
the interface to a service is by using an extended service grounding
that dynamically adds/removes information regarding intermediary
services that can resolve service composition conflicts.

I would be really interested to know what you think of this.

Again thanks for your help

Regards

Paul Fergus

-----Original Message-----
From: mithun sheshagiri [mailto:mits1@cs.umbc.edu] 
Sent: 06 January 2004 20:39
To: Fergus, Paul
Cc: public-sws-ig@w3.org
Subject: Re: Referencing multiple WSDL files using OWL-S

Please read below.....

Fergus, Paul wrote:

>Hello
> 
>I am doing some research on dynamically composting several Web services
from multiple locations. One of the main challenges in our work is to
try and form compositions with other services irrespective of whether
the service can directly accommodate a one-to-one composition. If the
service discovers that the type information is different but the
parameter names are conceptually equivalent we need to use the type
information associated with the two IOPEs and try to find a service that
can take as an input a value of type A and produce an output of type B,
which helps indirectly perform a conversion into the required type. 
> 
>I am having problems deciding how I use the OWL-S ontologies to
dynamically capture the information about composite services found. I
thought about extending the Process Model and use a Composite Process to
describe all the atomic processes that have been found (these could be
several Web services located on different servers) but to use an
additional property that defines the endpoint information where the
atomic process can be found.
>
If I understand you right, you actually need not extend the current 
specs. There is a mapping between each atomic process and WSDL operation

in the grounding. Therefore, if your composite process contains atomic 
processes with endpoints at different locations, their location can be 
extracted via the grounding file. There is no constraint that the atomic

processes should point to WSDL operations from the same service provider

> 
>Basically I want to use a OWL-S service ontology that can describe a
number of atomic processes located on a number of different servers.
> 
>I am not sure if this makes sense, however I would appreciate someones'
advice on this matter.
> 
>Thank you in advance for your time and effort
> 
>Regards
> 
>Paul Fergus
>  
>
Hope this helps

regards,
mithun

Received on Wednesday, 7 January 2004 05:01:50 UTC