- From: Mike Pool <mpool@iet.com>
- Date: Sat, 23 Aug 2003 19:49:33 -0400
- To: David Martin <martin@ai.sri.com>, "'www-ws@w3.org'" <www-ws@w3.org>
- Cc: epsl-writing@eeld.org
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 Thursday, 28 August 2003 09:04:27 UTC