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 <mailto: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