Re: [OWL-S] arguments for PAI and PAC

Oh, and I should add - we (the DAML-S Coalition) just recently had a 
vote on this, and we have decided to move from PAC to PAI.  This will be 
reflected in the next release of OWL-S (assuming no contravening 
decisions are made in the meantime, which I think is unlikely :-).

Regards,
David

David Martin wrote:

> 
> Hi Mike -
> 
> I appreciate your position on these issues.  Indeed, I initially favored 
> the processes-as-classes (PAC) representation myself, and I'm well aware 
> that PAC has several substantial arguments in its favor.  However, based 
> (partly) on my experience working with PAC, I've concluded that it's, 
> well, let's just say "more trouble than it's worth". I don't think 
> there's any way I can prove that processes-as-instances (PAI) will work 
> better, but I believe it will.  This is a pragmatic judgement, as I 
> think ontological modeling choices usually are.
> 
> I think we must beware of the hammer/nail tendency -- that is, the 
> well-known tendency of engineers that when we have a hammer, everything 
> looks like a nail.  A description logic, such as OWL, has some powerful 
> and well-documented capabilities in the area of characterizing class 
> membership.  But that doesn't mean that class membership is the only or 
> the most appropriate means for representing every important relationship 
> in the world.
> 
> It's important to note that the class/instance relationship is not the 
> only way available for us to model the relationship between a process 
> and its execution traces.  It has the virtue that one could use DL 
> subsumption algorithms to answer a question like "Is this execution 
> trace a valid instance of that process?".  But I'm not sure that it's 
> particularly important to be able to answer that particular question in 
> that particular way.
> 
> We don't normally model a car as the set of its parts, because we've 
> come to realize that it works better to use some other representational 
> mechanism for the "part-of" relationship.
> 
> Similarly, we don't usually represent the class of, say, dogs, as the 
> set of "life-traces" of individual dogs, or the class of humans as the 
> set of "life-traces" of individual humans.  (Note that I'm not saying we 
> should never do these things; just that we don't usually find it useful 
> to do so.)
> 
> I suppose the obvious rejoinder might be: in modeling processes we are 
> centrally concerned with behavior across time, so it *does* make sense 
> to think of a process as a class of executions (which we most often call 
> "execution traces" in our discussions).  And that thought is in the 
> spirit that initially motivated us to model processes in this way.  But, 
> at least in my view, experience has taught us that it's more natural to 
> think of a process, and an execution of the process, as two different 
> (though obviously very closely related) kinds of things, and model the 
> relationships in some other way than class membership.
> 
> Again, I can't give any "proof" that processes-as-classes doesn't work. 
>  I'm just making the pragmatic argument that it's too hard to work 
> with.  We're building an ontology, and in my view, if an ontology 
> doesn't reflect a natural way of thinking about a domain, it's not so 
> likely to be used.
> 
> Notice that someone else can still come along and employ a 
> processes-as-classes representation.  As you point out, it is possible 
> to think of a PAI representation as a user-friendly surface form that 
> maps into an underlying PAC representation.  And various people can 
> still do just that, if they find it to be sufficiently useful.  But, in 
> my view, the utility of the PAC representation isn't great enough to 
> warrant its continuation as a central part of our (the DAML-S 
> Coalition's) effort.
> 
> You could think of this as analogous to, say, the use of constraint 
> satisfaction algorithms to solve planning problems.  There is a vital 
> branch of work in which planning problems are mapped into constraint 
> satisfaction problems, and then solved using constraint satisfaction 
> techniques.  But this approach has not led planning researchers to 
> reformulate all of their plan representations into constraint-based 
> representations, or to use constraint-based representation as a common 
> underlying substrate for reasoning about plans.  Rather, those folks who 
> want to pursue this approach construct mappings from the predominant 
> plan representations into the constraint-based representations.  That's 
> roughly how I view the relationship between a process representation, 
> and the reasoning that could potentially be done about process execution 
> traces, using subsumption.  This kind of reasoning could be very useful 
> - but that fact isn't enough to compel us to adopt a less natural style 
> of representation for the mainstream work of representing processes.
> 
> That's all that my time constraints allow me to write just now.  But I 
> hope these comments at least shed some light on the directions of the 
> DAML-S Coalition in this regard.
> 
> Regards,
> David Martin
> 
> Mike Pool wrote:
> 
>> David and all:
>>
>> I've been following this discussion with some interest because the 
>> DARPA Evidence Extraction and Link Detection DARPA Program has been 
>> working on a pattern specification language, EPSL, and we have 
>> wrestled with similar issues.  I'm copying the group working on 
>> writing the EPSL specification.
>>
>> We have also been using a class level representation approach, i.e., 
>> we've used classes of pattern instances as the means by which to 
>> specify patterns much as DAML-S has hitherto used classes of 
>> "concrete" process instances or "traces" to specify a process, and 
>> we've seen DAML-S, to date, as a possible component or subset of EPSL, 
>> although our KR&R requirements differ somewhat.     I think you do a 
>> nice job of articulating some of the relevant issues.   I have a few 
>> comments and questions below.
>>
>> Please forgive if these questions/comments have already been made in 
>> ensuing discussions.
>>
>> best regards,
>> Mike Pool
>> At 10:08 PM 8/13/2003 -0700, David Martin wrote:
>>
>>
>>> 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.
>>
>>
>>
>> Yes, I think that this is true,  However, isn't there another solution 
>> here?   Couldn't some kinds of "macros" or abbreviations be introduced 
>> that don't explicitly specify the class at the level of detail at 
>> which it could possibly be represented but which could act as a 
>> pointer to the more detailed specification if some reasoning modules 
>> will require it and left out if they don't.  We haven't been using 
>> sequences, etc., very much in EPSL; however, should they be necessary, 
>> we introduced the following vocabulary to support it, invoking the 
>> DAML-S definitions indirectly, so that pattern creators could save a 
>> bit of effort.  This approach would also meet the goal of making the 
>> services vocabulary usable while pointing to an answer to the 
>> question, "but what's the semantic import of such a list?"   Couldn't 
>> OWL-S have such abbreviation predicates?
>>
>>
>> <rdf:ObjectProperty rdf:id="sequenceList">
>> <daml:ObjectProperty rdf:ID="sequenceList">
>>   <rdfs:comment> sequenceList(Class,CS-List) means that Class is the 
>> class of complex processes that are defined in terms of the sequence 
>> of events in the order and of the type indicated by the list of 
>> sequence types given in CS-List.
>>   </rdfs:comment>
>>   <rdf:domain rdf:resource="ePSL:ProcessGeneral"/>
>>   <rdf:range rdf:resource="ePSL:ControlStructureList-Simple"/>
>> </rdf:ObjectProperty>
>>
>> (sequenceList,S,<A,B,C,D,...,N>) is specified informally, however, as 
>> a stand-in for the analogous DAML-S construct:
>>
>> <daml:Class rdf:ID="S">     <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="#A"/>
>>                     <daml:Class rdf:about="#B"/>
>>                     <daml:Class rdf:about="#C"/>
>>
>>                            .
>>
>>                            .
>>                     <daml:Class rdf:about="#N"/>                  
>> </process:listOfInstancesOf>
>>                 </daml:Class>
>>               </daml:toClass>
>>             </daml:Restriction>
>>           </daml:intersectionOf>
>>         </daml:Class>
>>       </daml:toClass>
>>     </daml:Restriction>
>>   </rdfs:subClassOf>
>>   <rdfs:subClassOf>
>> </daml:Class>
>>
>> Note that we've done away with the rich representation in the PAC 
>> representation but we're acknowledging that the meaning could be 
>> represented in that way.  Hence, we could write translator, parser or 
>> reasoning facilitation code that would recognize 'sequenceList' usages 
>> and redefine them in terms of the more primitive DAML that DAML-S 0.7 
>> uses if that level of representation will facilitate further 
>> reasoning.   So, while an end user could simply use <sequenceList>, 
>> our reasoning tools could turn that into the more sophisticated 
>> DAML/OWL representation. 
>>
>>
>>> 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.
>>
>>
>>
>> But how would you implement the "instance level" representations?   As 
>> a matter of fact, we are reasoning about classes of objects when we 
>> represent prototypes of the sort  that are being suggested, aren't 
>> we?  These instance level prototypes help the "naive" user to think 
>> about the representation of a class of processes in a manner that 
>> facilitates representation and elicitation, but when we use prototypes 
>> aren't we actually finding a way to sneak in an implicit and ergo 
>> painless universal quantification on the user?   However, 
>> wouldn't/shouldn't we ultimately grok that in DAML-S/OWL-S by 
>> recasting those prototypes as classes of process instances?
>>
>>
>>
>>> 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)
>>
>>
>>
>> I agree that they're not well-supported, but are they questionable?   
>> I think we're actually brought back to the worry/question I was 
>> voicing above.  If one uses instance level representations of 
>> processes it seems to me that these are characterizations of a class 
>> of objects done in a user friendly manner, but to do the "under the 
>> covers reasoning" required of these prototypes we'll really still need 
>> to avail ourselves of the class representation, won't we?   Hence, 
>> perhaps this just means that we really do need support for classes of 
>> classes of first-level objects.
>>
>>
>>
>>> ====================================================================
>>>
>>> PAI-3. Seems to me it's more intuitive to think of processes as 
>>> instances
>>> than as classes.
>>
>>
>>
>> I disagree.   I agree that it may be easier for a user to represent a 
>> class of processes by trying to describe a typical process.   However, 
>> in terms of engineering/reasoning/inference support it just seems a 
>> lot easier/intuitive to replace every one of these "prototypical 
>> instances" with a class/set and represent "instantiations" or 
>> "realizations" as instances/elements of the class/set.  (Your PAC-3 
>> below.)
>>
>>
>>
>>> 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.
>>
>>
>>
>> I think that this is true, i.e., it's true that people often have 
>> trouble reasoning about classes and classes of classes.  However, once 
>> again, we're still left with the question of how to cash out the 
>> meaning of the prototypes if that is the tool that we use to overcome 
>> this difficulty.  If the meaning of the prototype ultimately gets 
>> specified via classes, does it make sense to keep a PAC representation 
>> around as the bedrock upon which either prototypes or "abbreviations" 
>> of the sort I mention are based upon?
>>
>>
>>
>>> 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".
>>
>>
>>
>>
>> Yes, exactly.
>>
>>
>>
>>> ====================================================================
>>> ====================================================================
>>> ====================================================================
>>> ====================================================================
>>>
>>> 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/>
>>
>>
>> Yes, this offers the same sort of representational shortcuts as our 
>> 'sequenceList'. 
>>
>>
>>
>>
>>
>>
>> ___________________________________________
>> Mike Pool
>> Information Extraction & Transport, Inc. 1911 North Fort Myer Drive, 
>> Suite 600 Rosslyn, VA 22209 USA (703) 841-3500 x632 (703) 841-3501 Fax 
>> mpool@iet.com
>>
>>
>>
> 

Received on Wednesday, 27 August 2003 16:11:08 UTC