RE: OWL-S dynamics

OK, thank you very much - I will have a look at them as soon as I have some
time. Regards

-----Mensaje original-----
De: Massimo Paolucci [mailto:paolucci@cs.cmu.edu] 
Enviado el: lunes 13 de diciembre de 2004 17:03
Para: Camara Melgosa, Javier
CC: public-sws-ig@w3.org
Asunto: Re: OWL-S dynamics


Javier,

If I understand your message correctly, you would like an execution
semantics for OWL.  Such a semantics has been defined in two papers:


*	Narayanan, S. and McIlraith, S.
<http://www.ksl.stanford.edu/people/sam/nar-mci-www11.ps> ``Simulation,
Verification and Automated Composition of Web Services''. To appear in the
Proceedings of the Eleventh International World Wide Web Conference
(WWW-11), May, 2002. 



*	Anupriya Anklolekar, Frank Huch, Katia Sycara. "Concurrent
<http://www-2.cs.cmu.edu/%7Esoftagents/atlas/pubs/ISWC2002-ExSem.pdf>
Execution Semantics for DAML-S with Subtypes ." In The First International
Semantic Web Conference (ISWC), 2002. 

the latter has been implemented in a computational mechanism for the
execution of the OWL-S/DAML-S Process Model 


*	Massimo Paolucci, Anupriya Ankolekar, Naveen Srinivasan and Katia
Sycara, "The DAML-S
<http://www-2.cs.cmu.edu/%7Esoftagents/papers/iswc2003.pdf> Virtual Machine
," In Proceedings of the Second International Semantic Web Conference
(ISWC), 2003, Sandial Island, Fl, USA, October 2003, pp 290-305. 

As for discovery in OWL-S, there have been a good number of papers.


*	Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara;
"Semantic  <http://www-2.cs.cmu.edu/%7Esoftagents/papers/ISWC2002.pdf>
Matching of Web Services Capabilities."  In Proceedings of the 1st
International Semantic Web Conference (ISWC2002) 

*	Lei Li and Ian Horrocks. A software framework for matchmaking based
on semantic web technology. In Proc. of the Twelfth International World Wide
Web Conference (WWW 2003), pages 331-339. ACM, 2003. 

As for the relation with UDDI you can look at:


*	Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara;
"Importing the  <http://www-2.cs.cmu.edu/%7Esoftagents/papers/Essw.pdf>
Semantic Web in UDDI" . In Proceedings of Web Services, E-business and
Semantic Web Workshop 

...and there are many other papers.  The papers I list here are the ones
that are on top of my mind.
I wonder whether these papers could help answering some of your questions.  

--- Massimo

Camara Melgosa, Javier wrote: 

Hi all. Maybe this is sort of a too basic question, but there he goes.
 
One of the things that most puzzles me when I read the OWL-S overview is
that it describes the information that can be specified for existing web
services, but it gives almost no clue on how this information could be used,
i.e. its dynamics. I guess the idea is, once one has some OWL-S documents,
to load them into some OWL engine and then start doing queries (reasoning)
on them as one whishes.
 
(Whatever you think about the rest of this message, I reckon that in order
for people to better understand OWL-S you should include some examples not
only on representation of existing services, but also on how agents would
use them.)
 
For me, this is somewhat like having the relational model, but no SQL or
ODBC/JDBC. I.e. one can take some OWL / OWL-S compatible product, load the
OWL-S documents into it and then start exploting them using the tools and
APIs of the product; but each such product has very different features and
ways to use it. It is as if UDDI would have included only the XSchema models
but not the API specs or the WS APIs; then one could create a XML DB with
this model and start querying it (well, at least now there is XQuery here) -
but UDDI has more than that.
 
I understand that this is not the goal of OWL-S, but anyway I think this is
needed in order for it to be a success; otherwise there will be so much
variety out there that OWL-S descriptions may well end up having to be
tailored for each case.
 
For example, how can discovery of web services be performed if one has
OWL-S? The overview does not tell. I guess it is up to one to use the
Profile at will. E.g. one could look only at the results and effects of the
profile, and leaving the task of dealing with inputs and preconditions to
the WS compositor (e.g. if a precondition is not met, maybe by calling
another WS we can fulfill it - for me this is one of the main goals of
composition).
 
If one has no previous knowledge about the ontologies used for results and
effects, then all one can use to discover services is search for things
being equivalent (in OWL terms) to the things we are looking for. So if we
are requesting results Rr, then we will look for existing profiles with
results Re equivalent to Rr. (At least one result being equivalent, or all
of them? Up to the discoverer, I guess).
 
However, I think this is somewhat limited and not much beyond what UDDI
does. E.g. maybe Re is not equivalent but part of Rr, and Re can be
completed later (e.g. through composition) to get the full Rr. Is this part
of a new relationship (to be made up by every discoverer)? Or can it be
achieved by unionOf et al OWL constructs and so leveraged by any discoverer?
 
Now, if we have some previous knowledge (beyond OWL and OWL-S) about the
ontology of results and effects being used, one can issue queries about
them, e.g. "look for results equivalentTo Rr, or equivalent to Re". Let's
distinguish between the user of the discoverer (i.e. the equivalent to a
UDDI client) and the discoverer itself (i.e. the equivalent to a UDDI
server). If this previous knowledge about Re and Rr is owned by the user of
the discoverer, then the discoverer is not much more than sort of a OWL
query engine, and then every user of the discoverer must know about Re
containedIn Rr, so every one of them requesting Rr must issue the proper
query.
 
However, if it is the discoverer who knows about Re containedIn Rr then
every user must just state that it wants Rr to be performed, and leaving the
discoverer deal with the details, which is the way I would like a discoverer
to work. But assumming we want generic, not hard-wired discoverers, how is
this knowledge defined to them?
 

For example, let's take what I believe to be a realistic internal corporate
integration scenario: let it be Rr "the department D of the person P in
which it performs the role R" (being P and R parameters), and Re "all the
departments Di of the person P" (being P a parameter). Re is useful to
perform Rr (the resulting Di must be filtered after retrieved, but anyway
the goal is met), but they are not equivalent - but how does the discoverer
know this, without knowing about the ontology in which these results are
expressed?
 
Can this be expressed using static relationships between OWL classes or
instances? Maybe a way of doing so is having Re an instance of some
DepartmentOfAPerson class, and Rr a instance of some
DepartmentOfAPersonWithARole class which is also subclass of
DepartmentOfAPerson . I guess a discoverer could leverage this in some way
(however, it is up to it). Nonetheless, given the large number of different
data concepts (Person, Address, Name, ...) available in an internal
corporate integration, this does not look like appealing to me.
 
For me, a good way of expressing all this is to have Re and Rr being
instances of the same Retrieval class, and then having some logic condition,
associated to this Retrieval class (i.e. with previous knowledge about it),
checking when a Retrieval R1 is useful for obtaining a Retrieval R2 . And
then making this logic condition available to the discoverer, along with the
ontology in which the Retrieval class is defined. And also more logic
conditions like this for the composition.
 
This is, I would propose for OWL-S to define a basic and extensible ontology
for effects and results, including in them these logic conditions to be
invoked by discoverers and compositors.
 
Any opinions on all that? Thank you very much for your time anyway
--
Javier Cmara (jcamara@softwareag.es <mailto:jcamara@softwareag.es> )
Software Architect, Software AG Espaa, S.A.
Ronda de la Luna, 22; 28760 Tres Cantos (Spain)
+34 91 807 9400, fax +34 91 807 9447
 

Received on Monday, 13 December 2004 16:06:11 UTC