RE: [OWL-S] Composition Templates

The point Bijan made is very important and relevant in pervasive/ubiquitous 
computing environment where the set of available services is different
from one environment to another. 

This is a different situation where one is dealing only with the Web Services 
always available on the Internet. 

For example, you might not want to have a composition that has,
as its constituent, a particular instance of "View on Projector" service 
which is available only in some particular environment 
(ex. in some conference room of some building).
The composition is useless as soon as you leave the environment. 

Instead you might want to have a composition that has, as its 
constituent, a "View" class service which is realized by a projector
with its resolution more than SVGA. 
The composition stays meaningful even if you move from one environment
to another. 

Regards,

Ryu

-----Original Message-----
From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On Behalf Of Bijan Parsia
Sent: Tuesday, January 13, 2004 4:15 PM
To: public-sws-ig@w3.org
Subject: [OWL-S] Composition Templates


One claimed advantage of Semantic Web Services, in general, and OWL-S, 
in particular, is support for *dynamic* composition. This can mean 
several things, but the sense I'm concerned with at the moment is 
late-selection of concrete services. That is, one specifies a 
CompositeProcess with "holes" in it that get filled with specific 
processes (either Atomic or Composite) later in the game. This is 
similar to certain recovery issues, i.e., what to do if while executing 
a CompositeProcess, one discovers that an AtomicProcess one needs to 
execute has gone off line -- one answer, select a relevantly equivalent 
replacement service and continue.)

OWL-S has perhaps two many abstraction points, at least potential ones. 
Profiles might abstract over various concrete processes (or, perhaps, 
we have classes of profiles). One might supply multiple groundings for 
an AtomicProcess (and, of course, there could be many bindings in the 
WSDL). But the canonical abstraction point is the SimpleProcess. 
SimpleProcesses are suppose to provide a "view" of a set of processes. 
A single SimpleProcess can be *realizedBy* many AtomicProcesses and 
simultaneously *expandsTo* many CompositeProcesses (themselves having 
component SimpleProcesses), or none at all (known to the system at some 
point). In principle, a composition system could look at the possible 
instantiations of each SimpleProcess and choose (or rechoose) the most 
desirable one.

So, "selection" of particular services is supported, but there's been 
no, to my knowledge, articulated story of how these options come to be 
known. That is, the two relevant predicates, expandsTo and realizedBy, 
express *hits* not queries. Thus, there is no current way to express 
"step three should be a service with these IOPEs and not cost more than 
$3 to invoke".

Fortunately, SWRL should make it pretty easy to express such things, 
simply with rules who's consquent is the relevant expandsTo or 
realizedBy (perhaps we should add a superpredicate to make the rules 
somewhat nicer to write?).  (Actually, one could do a fair bit with 
plain ole OWL classes with the appropriate restrictions).

So this all seems rather sensible to me. Is this pretty much the 
canonical story? Am I missing anything? Has anyone played with this 
sort of thing?

If it is, I think we should explicate it in our documents, and perhaps 
include something like this in an example.

Cheers,
Bijan Parsia.

Received on Tuesday, 13 January 2004 18:02:54 UTC