- From: Jun Shen <jshen@it.swin.edu.au>
- Date: Fri, 10 Dec 2004 10:10:56 +1100
- To: "'Camara Melgosa, Javier'" <JCAMARA@softwareag.es>, <public-sws-ig@w3.org>
- Message-ID: <001601c4de44$56ba0330$9b07ba88@JSHENPC>
Hi, maybe because OWL-S website is not updated frequently, there're a lot of emergent papers in recent conference/journals discussing your questions though not providing all promising answers. Follow this mail list archive you can also find some. Good luck. cheers Jun -----Original Message----- From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On Behalf Of Camara Melgosa, Javier Sent: Thursday, December 09, 2004 9:20 PM To: public-sws-ig@w3.org Subject: OWL-S dynamics 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 Cámara (jcamara@softwareag.es) Software Architect, Software AG España, S.A. Ronda de la Luna, 22; 28760 Tres Cantos (Spain) +34 91 807 9400, fax +34 91 807 9447
Received on Thursday, 9 December 2004 23:11:34 UTC