[OWL-S] arguments for PAI and PAC

Folks -

With respect to our recent telecon discussions on the possibility of 
switching to a representation in which the process is an OWL instance 
(instead of a class) I've made a fledgling effort to summarize some of 
the arguments favoring processes-as-instances, and some favoring 
processes-as-classes.  (I should say, however, that I've put more effort 
into processes-as-instances.)

Perhaps this can provide a starting point for some further discussion.

The file is being maintained here:

http://www.ai.sri.com/daml/daml.org/services/daml-s/instances/arguments.txt

and the contents are copied below.

Note that both my and Massimo's versions of Process.daml for instances
are also on this page:
   http://www.ai.sri.com/daml/daml.org/services/daml-s/instances

and several other relevant files.

- David

PAC = Processes as Classes
PAI = Processes as Instances
PAC-1, PAC-2, etc. are arguments favoring PAC
PAI-1, PAI-2, etc. are arguments favoring PAI


====================================================================
====================================================================
PAI Pros
====================================================================
====================================================================

PAI-1. It allows us to specify things much more tersely, and much more
readably.

I guess at the heart of my concern is a conviction that, with our
current approach, our process model has absolutely no chance of being
used by a mainstream developer to specify a Web service (even many of
those who understand and support the use of ontologies) - I think
it'll just be rejected outright, because it's so hard to think about
and work with.

I realize that even if it's not used by developers for
"hand-editing", that doesn't rule out its use by tools - but I'd
prefer to have something that can be used both ways if possible.

See Appendix A for an example.


====================================================================

PAI-2. PAC forces us to use constructs that are questionable and/or
not well-supported (e.g., PowerSet)

====================================================================

PAI-3. Seems to me it's more intuitive to think of processes as instances
than as classes.

Some of our current PAC constructs aren't well-defined, or were only
recently cleaned up (e.g., "invocable") - evidence that PAC is hard to
think about.  For instance, there are several places where we
incorrectly specified X as range, and then realized that we needed
XPowerSet.  I think specifying X is a natural tendency, because it's
much easier to think about.

Note: Have a look at Loops!  (I don't recall the details but I think
there are problems there.)

====================================================================

PAI-4. PAC forces us to use OWL FULL

???? But not sure about PAI

====================================================================

PAI-5. We don't have the luxury of time.  If processes-as-instances
helps us to move forward more quickly with the 1.0 release and
examples, etc., that in itself has value.  Note that the OWL-S process
model may eventually be superseded by whatever SWSL comes up with.
That makes me think we might as well take the current opportunity
(OWL-S 1.0 release) to heed the comments from various quarters that
the process model is too complex, and to follow Jim Hendler's
initial advice: "get out something that provides a 80% solution, and
can be quickly understood and put into use for relatively simple
cases".

====================================================================
====================================================================
PAC Pros
====================================================================
====================================================================

PAC-1. Some feel that PAC has a certain elegance.

====================================================================

PAC-2. There's a hope that PAC will support greater use of DL--based
reasoning - but this hasn't been demonstrated.

====================================================================

PAC-3.  With PAC we get instances as "execution traces" (and their
relationship to processes) "for free".

====================================================================
====================================================================
====================================================================
====================================================================

Appendix A:

Here's how the control structure for FullCongoBuy looks, in our current
(class-based) approach, and then in my draft instance-based approach.
Note that
the current approach would actually be much longer and less
comprehensible if it
didn't make use of listOfInstancesOf, which is a controversial construct.


BEFORE:

<daml:Class rdf:ID="FullCongoBuy">
   <rdfs:subClassOf rdf:resource="&process;#CompositeProcess"/>
   <rdfs:subClassOf>
     <daml:Restriction>
       <daml:onProperty rdf:resource="&process;#composedOf"/>
       <daml:toClass>
         <daml:Class>
         <daml:intersectionOf rdf:parseType="daml:collection">
           <daml:Class rdf:about="&process;#Sequence"/>
             <daml:Restriction>
               <daml:onProperty rdf:resource="&process;#components"/>
               <daml:toClass>
                 <daml:Class>
                   <process:listOfInstancesOf
rdf:parseType="daml:collection">
                     <daml:Class rdf:about="#LocateBook"/>
                     <daml:Class rdf:about="#CongoBuyBook"/>
                   </process:listOfInstancesOf>
                 </daml:Class>
               </daml:toClass>
             </daml:Restriction>
           </daml:intersectionOf>
         </daml:Class>
       </daml:toClass>
     </daml:Restriction>
   </rdfs:subClassOf>
</daml:Class>

AFTER:

<process:CompositeProcess rdf:ID="FullCongoBuy">
   <process:composedOf>
     <process:Sequence>
       <process:components rdf:parseType="daml:collection">
         <process:ProcessComponent rdf:about="#LocateBook"/>
         <process:ProcessComponent rdf:about="#CongoBuyBook"/>
       </process:components rdf:parseType="daml:collection">
     </process:Sequence>
   </process:composedOf>
<process:CompositeProcess/>

Received on Thursday, 14 August 2003 01:08:27 UTC