W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

Re: [owl-s] Re: Parameter puzzlement

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Sat, 11 Oct 2003 08:35:58 -0400 (EDT)
Message-Id: <200310111235.h9BCZwL03303@pantheon-po02.its.yale.edu>
To: www-ws@w3.org

   > 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.


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


   >  mention the
   > execution trace means ...

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

   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).

   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.

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

                                             -- Drew

                                   -- Drew McDermott
                                      Yale Computer Science Department
Received on Saturday, 11 October 2003 08:35:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:10 UTC