- From: David Martin <martin@AI.SRI.COM>
- Date: Wed, 27 Aug 2003 12:21:29 -0700
- To: Mike Pool <mpool@iet.com>
- Cc: "'www-ws@w3.org'" <www-ws@w3.org>, epsl-writing@eeld.org
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 15:22:22 UTC