Re: agents

The full specification of IOPEs is done in the process model, not in 
the profile.
Profiles are purely provided for the purposes of registering services 
with a registry, to enable matching. Thus, the IOPE descriptions 
provided there may not be as detailed in multiple ways as is required 
with the process model. The process model must provide precise 
semantic correlates for all inputs and outputs that are possible in 
the WSDL messages that they correspond to, and must link these data 
to the corresponding preconditions and effects so that a service 
requester can mechanically determine whether and how it will provide 
the correct inputs and interpret the resulting outputs.

The only reason that Xuan is assuming that one can do away with this 
is that he is looking at only atomic services, and he has observed 
that the service profile models have the same provision to describe 
IOPEs, not understanding that their intended use and level of 
specificity was different. Service profile IOPEs can be very 
incomplete with respect to what is required for the client to 
correctly call the service.

As to Jorge's original questions (which should have been answered 
without this descent into nonsense)
What now?

What am I supposed to do with these files? Do I have to build my own 
agent to query them? Are there API's available on the community?

If you look at the materials on the OWL-S website 
(www.daml.org/services) you will find pointers to some tools that 
live mostly on semwebcentral.org.

The OWL-S files are intended to be consumed by OWL-S client agents 
that are then able to call the described services. So they must be 
available on the web. The tools that exist (though clearly still 
inadequate for robust use) include semantic matchmakers (that consume 
the service profiles) and execution machinery (that consume the 
process and grounding). The agent that you write must be able to 
select which web service to call (from those recommended by a 
matchmaker, for example) and must be able to reason logically about 
what information to provide to the selcted service by matching what 
it was trying to do against the process model of the selected 
service.  At a minimum, it must be able to match features of the task 
it wants to perform against the semantic types of the input 
parameters of the service, and produce the owl description of each 
input that can be translated (by the grounding) into an element of a 
wsdl message.

What's the typical use for these files? How do I integrate this 
information on my web server so agents can locate and "understand" the service?



At 09:19 AM 7/24/2006, Xuan Shi wrote:

>Actually you just selectively and purposefully ignored those two
>fundamental but fatal problems for OWL-S. If a service provider ONLY
>provides ONE hotel reservation service, why does the provider need a
>process.owl document? How does this service provider know that the
>requester will use this specific service with the other 3, 4, 5 or 6
>services, or the requester will just use this single service? If service
>provider cannot handle and control the requester's behavior, then
>process.owl or OWL-S is just a nonsense.
>
>Regards,
>
>Xuan
>
> >>> Bijan Parsia <bparsia@isr.umd.edu> 07/24/06 5:51 AM >>>
>
>On Jul 23, 2006, at 7:29 PM, Xuan Shi wrote:
>
> > OWL-S is a mixture of *service-related* issues. As Bijan said, if you
> > are a service provider, normally "there won't be a lot of process to
> > describe". This means, once a service provider describes IOPEs for the
> > service, that's enough (service.owl, profile.owl).
>
>Well, that's not what I said, and that's not what I meant, and you
>used selective quotation to achieve this misrepresentation.
>
>In <http://lists.w3.org/Archives/Public/public-sws-ig/2006Jul/
>0019.html>, I wrote:
>
>"""(There's no requirement for separate files. ******IF YOUR SERVICE
>IS ATOMIC******, there
>won't be a lot of process to describe).""" [emphasis added]
>
>"If you are a service provider" is in no way a paraphrase of "if your
>service is atomic".
>
>And it certainly doesn't mean that describing a services IOPEs for a
>process "is enough". I clearly was pointing out that a "process.owl"
>for an atomic process might be quite small, with the clear
>implication trat the profile might be quite bulky.
>
>I expect a retraction of your culpable, yet stupid as you included
>them below, misrepresentation of my words.
>
>As to the rest of your nonsense, I have no other comment but to note
>that it is both nonsense and completely unresponsive to the original
>poster.
>
>Cheers,
>Bijan.