Re: Data Flow

On Thursday, October 9, 2003, at 08:50 PM, Massimo Paolucci wrote:

[snip]
> While the two proposals seem to be quite distant, there is a simple
> way to combine them using the owl sameAs construct.
>
> From the owl reference document:
>
>     The built-in OWL property owl:sameAs links an individual to an
>     individual. Such an owl:sameAs statement indicates that two URI
>     references actually refer to the same thing: the individuals have
>     the same "identity".
>
> We could then say that there are inputs and outputs parameters, and
> that the data flow is then represented by asserting a sameAs relation
> between an input and an output.  Effectively those input and output
> become the very same object in the context of the process model, which
> looks very similar to Drew's channel proposal.

Does it make sense for them to be the same object?  Aren't inputs and 
outputs, well, different things? Hmm. Actually, that might work much 
better than I just thought. Need to ponder more.

> A somewhat better way to do the same thing is to define a new property
> "dataLink" that is a subproperty of sameAs but is restricted to relate
> outputs to inputs.

I think this is illegal in DL. FWIW. In some sense, it might be "ok" in 
the sense that it's really just a syntactic trick. But I would want to 
check. I'm less adverse to doing things that are "DLable" but happen 
not to be DL, than I am to doing robustly OWL full things.

OTOH, if we have a bonafide surface syntax that diverges plenty from 
the owl, that's the right place to put the macro.

> This property is defined as follows.

> <owl:ObjectProperty rdf:ID="dataLink">
>  <rdfs:subPropertyOf rdf:resource="&owl;#sameAs"/>
>  <rdfs:domain rdf:resource="#Output"/>
>  <rdfs:range rdf:resource="#Input"/>
> </owl:ObjectProperty>
>
>
> The advantage is that we introduce some sort of directionality to data
> links,

Except, uh, 1) sameAs is symmetric, right? Plus, anything on either 
side will be *both* an Input and an Output. So no directionality. 
Nothing *but* identity. You can't be a little bit sameAs.

>  and we allow for some control on the validity of process
> models: any process model that defines a dataLink departing from an
> input would be invalid and we can detect that.

I think my line above refutes this. If they the same, then EVERY 
datalink departs from an input.

> We could also gain more control on the description of the process
> model by adding the following two statements which constrain the
> values of any input to be set by an output.  Note that there is no
> restriction on outputs, so any output can set may inputs.

[snip the more control proposal]

I think this falls afoul too. If you aren't convinced by my informal, I 
could try to show it in an ontology.

> My vote as usual goes for the highest level of control so I would add
> to the Process Model the properties dataLink and dataFrom, and the
> restriction on Inputs.

To sum, I think the subpropertying is non DL (FWIW) and the 
subPropertying doens't have the effect you want. However, the basic 
proposal may work, and well! But I'm not entirely sure and would wan to 
develop some examples.

I think it doesn't conflict with my parameterType proposal, either.

Cheers,
Bijan Parsia.

Received on Thursday, 9 October 2003 21:17:49 UTC