[owl-s] Re: My version of my proposal (was Re: My version of Bijan's proposal)

[To www-ws ers: Sorry about the lack of context. Migrting a thread.]
On Friday, October 10, 2003, at 12:37 AM, David Martin wrote:

> Bijan Parsia wrote:
>
>> On Thursday, October 9, 2003, at 09:28  AM, Drew McDermott wrote:
>> [snip]
>>> The glitch is that we can't really use actualParameterValue the way 
>>> it
>>> is used in the examples.  The value of a parameter is different each
>>> time the process is invoked, except in odd cases which are not
>>> relevant here.
>> This proposal explicitly dealt with that. That's why you need a 
>> ValueSpec which is analogous to a binding in a trace. I even 
>> explained that fact :) At length!
>>> Even so, the notation does seem to say what we want to say.  I'm just
>>> wondering if we can't simplify it.  Why not do away with
>>> ParameterValueSpecs, leaving us with:
>>>
>>> <owl:Class rdf:ID="AirportInput">
>>>     <rdfs:subClassOf rdf:resource="http://www.mindswap.org/
>>>                             
>>> ~bparsia/ontologies/sws/iope-exp.owl#Input"/>
>>>     <rdfs:subClassOf>
>>>         <owl:Restriction>
>>>             <owl:onProperty rdf:resource="http://www.mindswap.org/
>>>                             
>>> ~bparsia/ontologies/sws/iope-exp.owl#parameterValue"/>
>>>               <owl:allValuesFrom rdf:resource="#Airport"/>
>>>         </owl:Restriction>
>>>     </rdfs:subClassOf>
>>> </owl:Class>
>>>
>>> Actually, this is rather nice.  The property parameterValue then
>>> obtains between any parameter and all the objects that are potential
>>> values of that parameter in execution traces.
>> That was my original thought, but it doesn't handle type checking of 
>> actual bindings. Because there is no way to distinguish particular 
>> values as being related to a particular binding in a particular 
>> context.
>
> One way to make this approach a little nicer would be simply to do 
> both (both the original thought and the more sophisticated, 2-leveled 
> approach).

I don't think this is *nicer*. At least not to my taste.

> Simply have 2 properties.  The parameterValue property (say) would be 
> used in the way that Drew describes (and which was Bijan's original 
> thought).  But it probably wouldn't get any practical use.

[In a clarification you wrote "I should have said: Instances of the 
property would never be created for any practical purpose."]

This is exactly why I object to it: it's hard to give it any *sensible* 
reading.

>  It would just be there for the purpose of declaring inputs.

Why not just do this in the surface syntax then? I mean, you basically 
claim it *is* surface syntax!

Remember that this *was* my original thought. Why was I driven away 
from it? Not for the inferences sake. YOu can get the typechecking with 
either. It was because, however verbose, the two level approach 
captures (or hasn't yet been shown not to) what's actually going on.

> So, I take it, DepartureAirport_In would get declared like this:
>
> <owl:Class rdf:ID="AirportInput">
>   <rdfs:subClassOf rdf:resource="iope-exp.owl#Input"/>
>   <rdfs:subClassOf>
>       <owl:Restriction>
>         <owl:onProperty rdf:resource="iope-exp.owl#parameterValue"/>
>         <owl:allValuesFrom rdf:resource="#Airport"/>
>       </owl:Restriction>
>    </rdfs:subClassOf>
> </owl:Class>
>
> <AirportInput rdf:ID="DepartureAirport_In"/>
>
> <AtomicProcess ID= "ReserveFlight">
>    <hasInput rdf:resource="#DepartureAirport_In"/>
>    ... other properties ...
> </AtomicProcess>
>
> Then there could be another property (of Parameter), called, say 
> parameterValueTrace, which could have AirportInputValueSpec as its 
> range, and it could be used for reasoning purposes with respect to 
> individual execution traces.

How do you enforce the constraint that parameterValue and 
actualParameterValue have the same type?

Plus, I mean, is this a parameter*Value*? Perhaps.  A 
possibleParameterValue or some such.

> People who are only interested in declaring inputs, then, would never 
> have to look at the 2-layered approach.

If we're going this route, we should prolly just give up the two layer 
approach. Doing that for syntactic simplicity is, well, strongly 
against my inclination.

I'll note that you can't use the simple approach for dealing with 
conditoinal outputs.Or dataflow (think there may be a way to do it. You 
may not like it ;)) Incidently, it requires two parameterValues 
properties, one for datatypes. (2 layer isn't really better off, as it 
requires two ValueSpec classes to inherit from)

(Conditional ouputs: You have a condition property as well as a actual 
value property on outputValues, and express, say, the constraint that 
this output is restriction to all values from the union of on 
InputValueSpec(IVS) restricted on value to type1 and on condition to 
cond1, and a IVS restricted on value to type2 adn on condition to 
cond2, etc. Wow, that, I think, very neatly does the job!)

One thing I'd like to be clear on: the "original thought" is a kluge 
and something of a hack representationally (at least, unless I think of 
it as a possibleParameterValue, and then it seems interpretable, but 
not extensible). I don't believe that that's the case with my approach.

Cheers,
Bijan Parsia.

Received on Friday, 10 October 2003 07:24:12 UTC