[owl-s] Re: Parameter puzzlement

On Friday, October 10, 2003, at 11:56  AM, Drew McDermott wrote:

> [I'm reposting this to www-ws, although at this point I'm really
> repeating what Mark Burstein said.]

However, you were still saying that you didn't *get* it, in telecon. 
That's a bit differnt :) I shall try to quickly explain, but we may 
have to take it up after Fla.

> I'm sorry to be so obtuse, but I still don't get Bijan's argument:
>
>    One point I think I failed to actually write out is the rationale 
> for
>    the double levels.
>
>    You can't really put the value on the Input itself because there'd 
> be
>    no way to distinguish *which* value you  were talking about in what
>    context. There has to be some metadata on the value.
>
>    If Inputs were classes, then it would work to have the value 
> straight
>    on. I.e., Input instances would *be* those trace level inputs
>    representations.
>
> Here is his example, expressed in some kind of bastardized predicate
> calculus

I'm not yet clear whether this was supposed to be a transliteration of 
my example, or my example expressed a different way.

> (please skip to the three triples at the end if you prefer
> the original notation):
>
> (subclass AirportInput Input)
>
> (forall (x v)
>    (if (and (rdf:type x AirportInput)
>             (parameterValue x v))
>        (rdf:type v AirportInputValueSpec)))

It's the immediately prior bit I don't know what to do with. I don't 
think it can be expressed (easily) in OWL, unless I'm just being dense.

Hmm. Is this supposed to be the restriction? Ah, ok, now I see it.

> (subclass AirportInputValueSpec ParameterValueSpec)
>
> (forall (y x)
>    (if (and (rdf:type y AirportInputValueSpec)
> 	    (actualParameterValue y x))
>        (rdf:type x Airport)))
>
> (rdf:type departureAirport_In  AirportInput)

Ok.

> // So departureAirport_In is an individual input parameter.  But it
> ;; will have different values in different execution traces.
>
> (parameterValue departureAirport_In ivs1)
>
> (rdf:type ivs1 AirportInputValueSpec)
>
> (actualParameterValue ivs1 Logan)
>
> It's that last pair of assertions that does me in.  I just don't
> understand what the symbols mean well enough to get a clear picture of
> what's being asserted.

isv1 is a (radically incomplete) decription of a binding of that input 
in a particular execution.

The only thing we know about it is that it was about a binding to a 
particular value, Logan.

It could have other information, like time of binding, etc.

> We have some kind of route from the parameter
> to Logan:
>
>     departureAirport_In ---- [ ivs1 ? ] ----> Logan
>
> But all this can possibly mean is that Logan is a legal value for the
> parameter.

Well, the last two assertions (above) make the claim that there *is* a 
binding (in some specific execution trace), and that it has the value 
Logan. However, we can prove that that is consistent with the rest of 
the ontology (i.e, the description of the type of values of the input).

It's not ALL we could ever do, of course. It was just demonstrating.

> Even if 'ivs1' is supposed to connote the value on a
> particular execution trace, the fact that we don't ever

yet

>  mention the
> execution trace means that the relationship between
> 'departureAirport_In' and 'Logan' is
>
>      ivs1 is a possible (placeholder for the ?) value of
>          departureAirport_In on some execution trace
>      Logan is a the actualValue of ivs1 in that trace
>
> But this is just a long-winded way of saying that Logan is a possible
> value of 'departureAirport_In'.  What else can I glean from it?

Nothing. You'd have to have a lot more information in the ontology to 
do that. i didn't put it in because it's not a complete example. I 
didn't claim it was.

> I'm sure I'm missing something.

Two things, actually.

>  Maybe Bijan sees parameterValue as
> the vanguard of a whole vocabulary for describing execution traces.

Yes. That's one.

> For instance, there might be a way of saying that two InputValueSpecs
> are from the _same_ execution trace, in which case we could begin to
> infer, for instance, that on this trace departurePassenger_In Parsia
> went from departureAirport_In Logan to arrivalAirport_Out BWI.

Sure.

> Please enlighten.

Ok, it seems that one thing you'd like to infer about a process model 
is whether its type consistent, that is, that the type of any input is 
compatible with the type of an output its linked to. I believe that I 
can follow up on this technique to express that. Hmm. Ok, that's not 
determinative, since I can do it with the one level, probably.

I think we can express other things, like conditional outputs, very 
naturally with this represenation. You can put a condtion property on 
the valuespec and make it an instance of a pair of restrictions on the 
condition and actualvalue, respectively.

I think it can work for dataflow too. Oops, as you said above. We need 
not focus on trace reasoning, of course, but it could allow us to 
express or constrain dataflow links as restrictions.

The nice thing, I think, about this technique is that it's fairly 
uniform, and built on the trace/process connection. Indeed, it allows 
us to express process descriptions *as* constraints on possible traces.

Perhaps I have boostrapped my self back into a *kind* of processes as 
classes, but certainly no processes as being just OWL classes. 
Processes are still individuals. But they are related to their traces 
(we hope).

Indeed, an extra special goody is that we recover exectution traces 
without going back to PAC. We gain actual useful reasoning, as well (so 
that, i hope, in the end, that the process model description is 
consistent only if the process model is type consistent).

Cheers,
Bijan Parsia.

Received on Friday, 10 October 2003 19:47:41 UTC