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