RE: OWL-S dynamics

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.

-----Original Message-----
From: [] On
Behalf Of Camara Melgosa, Javier
Sent: Thursday, December 09, 2004 9:20 PM
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
(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
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
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
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 (
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