Re: Referencing multiple WSDL files using OWL-S

Sorry for the delay.....

Fergus, Paul wrote:

>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 did not completely understand your approach. Does the unique ID gets 
resolved to different WSDL files based on changing IP addresses?
Assuming that the device advertises its services only after it connects, 
you could also post an updated grounding and WSDL file in the directory, 
to reflect the new IP, port etc.

regards,
mithun

>
>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 Monday, 12 January 2004 16:33:05 UTC