Re: [OWL-S]: Proposal for 3 new control constructs

On Jan 29, 2004, at 1:30 AM, David Martin wrote:

>
> In response to my re-post, Bijan wrote:
>
>> Just to extract the relevant bit from the other more contentious 
>> bits, suppose there were a superconstruct "call" which is the unionOf 
>> <invoke> and <accept> (and <select> could be modeled as the accept of 
>> a choice).
>> Hmm. Acutally, david, absent the resolution of binding, this doesn't 
>> make the reference/definition distiction, afaict.
>
> Bijan, either I haven't been clear enough about what I have in mind, 
> or I am completely missing what you are concerned about.
>
> In my proposal, the distinction between definition and reference is 
> straightforward:
>
> a process *definition* is given as an instance of class Process (as we 
> already do in 1.0), whereas
>
> a process *reference* is given as an instance of class Invoke, which 
> mentions some Process defined-elsewhere, using the "service" property, 
> e.g.:
>
>    <Invoke rdf:ID="MyProcessReference545">
>        <service resource="http://..../SomeService.owl">
>    </Invoke>

Ah...I missed that invoke was a class.

> Remember this was just an initial sketch.  Some of the details need 
> further elaboration, and some could change.
>
> But in any case, I fail to see how this approach fails to make the 
> reference/definition distinction.  I'm also not clear what you mean by 
> "absent the resolution of binding".

There are two key parts to a solution to process references, that they 
identify the "call site" (in PSL terms, the point of the activity tree 
that the process occures), i.e., establishing the flow of control, and 
that they indicate the dataflow.

There also needs to be some mechanism of distinguishing them. As you 
know, rdf:ID, due to the lack of a UNA in OWL, isn't sufficient.

However, I was too strong in saying that it failed to make the 
reference/definition distinction (mostly because when I see a leading 
lowercased tag name, I tend to think "property", but then I should have 
noted that "service" wasn't the right class either :))

>  My proposal included a simple approach to specifying the binding of 
> values to inputs of the invoked process.

Yes, but binding of *values* is typically an execution time issue 
(except for relatively rare cases when you have a known constant 
value). More typical, and tricky, is the co-binding of variables.

> (Again, some details remain to be fleshed out, such as the use of 
> variables in these bindings,

Well, that's a major challenge, IMHO :)

>  but we had some discussion about that in the last telecon, and 
> hopefully some of these details are forthcoming.)

That's good.

Cheers,
Bijan Parsia.

Received on Thursday, 29 January 2004 07:49:00 UTC