- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Sat, 11 Oct 2003 08:35:58 -0400 (EDT)
- To: www-ws@w3.org
[me]
> 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.
[Bijan]
isv1 is a (radically incomplete) decription of a binding of that input
in a particular execution.
....
[me]
> Even if 'ivs1' is supposed to connote the value on a
> particular execution trace, the fact that we don't ever
[Bijan]
yet
[me]
> mention the
> execution trace means ...
...
> Maybe Bijan sees parameterValue as
> the vanguard of a whole vocabulary for describing execution traces.
[Bijan]
Yes. That's one.
This seems like a classical example of why bottom-up design is wrong.
Rather than approach the problem of reasoning about execution traces
systematically, we have a little construct that _looks like_ it might
be part of the execution-trace system in the end. If we adopt it, we
may discover later that the best design doesn't use it, in which case
it'll either be a historical oddity left lying around, or we'll adopt
a second-best design just so we can say we used ParameterValue objects
after all.
What price do we pay for _not_ adopting it? None that I can
see. Using half of Bijan's idea, that is, having a property that means
"possible value," commits us to nothing at all in the execution-trace
system (except that values in execution traces must conform to the
declaration embodied in the restriction on possible values).
[Bijan]
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.
Yes.
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.
The whole reason for going to PAI was to be able to have a
straightforward ConditionalOutput class, and _not_ have to infer it by
roundabout reasoning.
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.
We don't _want_ to express them 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.
We don't _want_ to describe processes as constraints on possible
traces. We want them to be individuals whose properties tell us how
they are executed.
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).
Yes, but we need a coherent theory.
Why not produce one? Give us the whole thing instead of just this
little piece. Seriously.
Indeed, an extra special goody is that we recover exectution traces
without going back to PAC.
We aren't going to recover them piecemeal, or by accident.
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).
My guess is you can't get this property. But I would love to be
wrong.
-- Drew
--
-- Drew McDermott
Yale Computer Science Department
Received on Saturday, 11 October 2003 08:35:59 UTC