Re: Data Flow

Bijan Parsia wrote:

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

Actually,  the way I understand sameAs, it does not push the ontology 
directly in OWL Full, unless it is used to equate classes.  The OWL 
Reference states...



            In OWL Full, where a class can be treated as instances of 
(meta)classes, we can use
            the |owl:sameAs| construct to define class equality, thus 
indicating that two concepts
            have the same intensional meaning.

This is not what we are doing here.
 

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

First of all sameAs is a property and it is not defined as symmetric in 
the OWL specs (although I agree that that would make a lot of sense).  
But in general the attempt is to introduce constraints so that we can 
detect meaningless patterns.

>
>>  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 will try to send an example tomorrow.

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

I sort of like this ;-)

--- Massimo

Received on Thursday, 9 October 2003 22:00:24 UTC