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

    * Anupriya Anklolekar, Frank Huch, Katia Sycara. "Concurrent
      Execution Semantics for DAML-S with Subtypes
      <http://www-2.cs.cmu.edu/%7Esoftagents/atlas/pubs/ISWC2002-ExSem.pdf>."
      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 Virtual Machine
      <http://www-2.cs.cmu.edu/%7Esoftagents/papers/iswc2003.pdf>," 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 Matching of Web Services Capabilities." 
      <http://www-2.cs.cmu.edu/%7Esoftagents/papers/ISWC2002.pdf> 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 Semantic Web in UDDI"
      <http://www-2.cs.cmu.edu/%7Esoftagents/papers/Essw.pdf>. 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:03:26 UTC