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

Re: [owl-s] Re: Parameter puzzlement

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sat, 11 Oct 2003 09:14:37 -0400
Cc: www-ws@w3.org
To: Drew McDermott <drew.mcdermott@yale.edu>
Message-Id: <DD1FA0BD-FBEC-11D7-847C-0003936A0B26@isr.umd.edu>

On Saturday, October 11, 2003, at 08:35 AM, Drew McDermott wrote:

> This seems like a classical example of why bottom-up design is wrong.

I was just thinking the opposite.

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

Well,  I think I have *some* vision of the whole. I need to work it 
out, granted.

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

Well, I wasn't urging that we adopt it now, especially contrary to a 
more worked out account. But saying "We need the pudding before we have 
a proof" and "That doesn't or can't work, or is just an attempt to 
sneak things back in".

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

Well, I mobilized your argument against a similar proposal of David's 
(his was adopt both now, yours can be read as adopt the first half now, 
worry about the other half later). The problem with this is 
that....hm....I thought for a moment that the understanding of 
"parameterValue" reading was different than in the worked out view.  
THe problem I saw was that we might end up with a historical oddity in 
the other direction

But it probably doesn't. So, I think it's ok to adopt the original 
thought/first half. Espeically instead of the using owl:Class as the 
range of parameterType. I would like documented that we haven't 
*finalized* how the range of paremeterValue works.

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

You can have both, right? I mean, why *shouldn't* ConditionalOutput 
have a more elaborate defintion that allows use to get more out of it? 
I'm trying to get as much of the meaning of these constructs *manifest* 
in owl.

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

You don't want to constrain them that way?

Plus, that's either a "we" that doesn't include me, or a "we" statement 
that's false. I don't *not* want to express dataflow links as 

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

Have I denied otherwise? I said, I *believe* I can make it work, not 
that I have made it work. I've said that I *believe* it will be 
satisfying, coherent, and allow us to exploit OWL reasoners in a useful 
way, and that I have work to do to show it. How long has it been since 
I proposed it? Not even a week? I've spent a lot of time just trying to 
*explain*it to the rest of you! This first piece. Something  useful, I 
think, has come out of it already!

> Why not produce one?  Give us the whole thing instead of just this
> little piece.  Seriously.

Do I get time, or must I rush?

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

Thanks drew, for your kind evaluation of my research methodology.

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

My guess is otherwise, and I would love to be right. I'm prepared to be 
wrong. Should we take your guess as determinative of where I put my 

Bijan Parisa.
Received on Saturday, 11 October 2003 09:14:38 UTC

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