[owl-s] Re: My version of my proposal

(Responding to Bijan's desire to see this discussed on www-ws)

Below is an example I constructed following Bijan's model (see included msg 
at bottom) using as a starting point the DAML-S group's proposed 
BravoProcess owl-s example.

I see several issues/arguments to be made:

1. This approach is still trying to mix what is essentially a process as 
instance description with a mechanism geared to processes as classes (or at 
least the parameters of such processes described as classes).  For 
example,  AcctName_In in my example below is a dummy instance of 
AcctNameInput created solely to tie it to the ProcessAsInstance (PAI) 
description of LogIn without having a property point to a Class. (Maybe 
there is another way to do this, but I don't see it.)  At some level then, 
this seems to me not much better than just pointing to an anonymous 
instance of the AcctName class, which (the actual parameter range 
restriction we want to indicate). Both do the same thing to avoid OWL Full.

2. Much of the rest of the machinery is really to support the 
classification of parameter values in execution traces, which I would argue is
a somewhat separate issue from the PAI language for process descriptions, 
which, while perhaps not a surface language, is no longer describing
the structure of classes of process instances (traces) either.
I think we should discuss Bijan's proposal as PART OF a model of how to 
represent execution traces, but not as a part of PAI. I would claim that we 
shouldn't need to include these extra class definitions within each process 
model built using PAI - even if we believe that yet another surface 
language will be needed.

In moving to PAI, I would say we have "given in" to the idea that we are 
not going to do much reasoning directly on the process descriptions using 
OWL DL reasoners. We are really moving more to an RDF encoding of processes 
AS descriptions, much like we might have if we RDF-ized WSDL or BPEL. We 
are no longer defining classes that could represent execution trace 
descriptions.

If what we really have is effectively an RDF encoding of a process 
description, I would argue this may not be the right place to worry about 
avoiding OWL Full, so we might as well have inputs have parameterTypes that 
point to Classes (effectively parameter ranges). If there is one piece of 
the language that should NOT be distorted, it should be the relationship 
between types and process parameters (or types and channels - our mechanism 
for 'local process variables'). This is the bridge to reasoning we WOULD 
like to see in OWL, namely the formation of queries and inferences about 
what values can be provided as inputs to particular processes.  The special 
purpose reasoners that do get built to interpret process descriptions will 
want to do several specific kinds of things in my mind: 1) Identify sets of 
parameters and their type restrictions 2)  Identify conditions and 
effects  and 3) identify control and data flow relationships. To support 
the first one, the relationship between each parameter and the constraints 
on its allowed values should be easily found.

FWIW.

Mark

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

Current Proposed OWL-S 1.0 model:
           <process:AtomicProcess rdf:ID="LogIn">
                 <process:hasInput rdf:resource="#AcctName_In"/>
         </process:AtomicProcess>

         <process:Input rdf:ID="AcctName_In">
                 <process:parameterType 
rdf:resource="&concepts;#AcctName"/>   <!-- this is where we hit OWL Full -->
         </process:Input>

Drew's Proposal to avoid OWL Full by using an anonymous instance to stand 
for the class:
         <process:Input rdf:ID="AcctName_In">
                 <process:parameterType><concepts:AcctName/> 
<process:parameterType>
         </process:Input>


My extrapolation of Bijan's proposed model:


         <process:AtomicProcess rdf:ID="LogIn">
                 <process:hasInput rdf:resource="#AcctName_In"/>
         </process:AtomicProcess>

         <owl:Class rdf:ID="AcctNameInput">
           <rdfs:label>AcctNameInput</rdfs:label>
           <rdfs:subClassOf rdf:resource="&process;#Input"/>
           <rdfs:subClassOf>
             <owl:Restriction>
               <owl:onProperty rdf:resource="&process;#parameterValue"/>
               <owl:allValuesFrom rdf:resource="#AcctNameParamValueSpec"/>
             </owl:Restriction>
           </rdfs:subClassOf>
         </owl:Class>

         <owl:Class rdf:ID="AcctNameParamValueSpec">
           <rdfs:label>AcctNameParamValueSpec</rdfs:label>
           <rdfs:subClassOf rdf:resource="&process;#ParameterValueSpec"/>
           <rdfs:subClassOf>
             <owl:Restriction>
               <owl:onProperty rdf:resource="&process;#actualParameterValue"/>
               <owl:allValuesFrom rdf:resource="&concepts;#AcctName"/>
             </owl:Restriction>
           </rdfs:subClassOf>
         </owl:Class>


         <AcctNameInput rdf:ID="AcctName_In"/>









PRIOR MSG FOLLOWS=========================================
Subject: My version of my proposal (was Re: My version of Bijan's proposal)
Cc: daml-process@bbn.com
To: Drew McDermott <drew.mcdermott@yale.edu>
From: Bijan Parsia <bparsia@isr.umd.edu>

See:
         <http://www.mindswap.org/cgi-bin/2003/pellet/ 
pelletGet.cgi?inputString=&inputFile=http%3A%2F%2Fwww.mindswap.org%2F%7E 
bparsia%2Fontologies%2Fsws%2Fiope-consistent- 
example.owl&conclusionsFile=&classifyFormat=NONE>

and:
         <http://www.mindswap.org/cgi-bin/2003/pellet/ 
pelletGet.cgi?inputString=&inputFile=http%3A%2F%2Fwww.mindswap.org%2F%7E 
bparsia%2Fontologies%2Fsws%2Fiope-inconsistent- 
example.owl&conclusionsFile=&classifyFormat=NONE>

Which use a modified version of Marta's document at:
         <http://www.mindswap.org/~bparsia/ontologies/sws/iope-exp.owl>

(Links to the ontologies on the results pages above)

The basic idea is that Inputs have parameterValues. One for each actual
binding for that input. Each parameterValue takes a ParameterValueSpec
(which probably should be a paramtervalueTrace or something). The
ParameterValueSpec contains the actual value (actualParameterValue) for
that binding (it should also point to the particular trace and point in
that trace that its part of).

Type checking is enforce by making the Input also of be a member of a
Restriction which ultimate restricts the values of the
actualParameterValue to be of the desired type.

Whew!

As you can see from the examples, if you use a value from a disjoint
type (DeepWaterharbor vs. Airport) you get an inconsistency.

To handle both datatypes and individuals, we could have two types of
actualParamterValues (we may need two sorts of ParameterValueSpecs,
too).

This is all in owl DL and is actually quite easy for DL reasoners to
handle.

It is more verbose, but you do get some mojo for your money, and not
just, IMHO, that I've "hacked" up something acceptable to the reasoner.
I think this representation both reasoanbly natural, and in keeping
with other representational choices we've made. I don't think Value
specs are mere cruft.

There are still some issues to deal with and some experiments to make.

But I'm way exhausted and there's still miles to go on other stuff :)

I hope this is enough to decide whether this is worth pursuing.

Cheers,
Bijan.



         <AcctNameInput rdf:ID="AcctName_In"/>


* Dr. Mark H. Burstein <burstein@bbn.com>
* Director, Human Centered Systems Group
* BBN Technologies
* 10 Moulton Street
* Cambridge, MA 02138
*
* Tel: 617-873-3861
*  Fax: 617-873-4328
* http://daml.bbn.com/burstein

Received on Thursday, 9 October 2003 14:05:25 UTC