Re: Doubt about Parameter during execution

Hi Bijan -

Bijan Parsia wrote:

> 
> I'm not following the whole discussion, but...
> 
> On Jan 5, 2005, at 2:14 PM, David Martin wrote:
> 
>> Evren Sirin wrote:
> 
> [snip]
> 
>>> Yes, exactly. What I had in mind was a process description like this:
>>> <process:AtomicProcess rdf:ID="FindBook">
>>>    <process:hasInput>
>>>        <process:Input rdf:ID="BookName">
>>>            <process:parameterType 
>>> rdf:datatype="&xsd;anyURI">&xsd;#string</process:parameterType>
>>>        </process:Input>
>>>    </process:hasInput>
>>>    <process:hasOutput>
>>>        <process:Output rdf:ID="BookInfo">
>>>            <process:parameterType 
>>> rdf:datatype="&xsd;anyURI">&books;#Book</process:parameterType>       
>>>    </process:Output>
>>>    </process:hasOutput>
>>> </process:AtomicProcess>
>>>
>>>>  I think the parameterType makes confusion in my mind!!!! In the 
>>>> same way, did now the sintax of Parameter. As described at 
>>>> Process.owl file, a Parameter can have at minimum one parameterType. 
>>>> What does it mean?
> 
> 
> It can mean a few things (for example, that the type of the value is the 
> conjunction of the types), but I believe we meant for it to be 
> compatible with sub/super typing. No parameter has only one type. 
> (Probably no parameter.)
> 
>>>>  If it has more than one type, doesn't it have to have also the same 
>>>> number of parameterValue? (I thought it as an structured parameter) 
>>>> How can one Parameter have more than one type?
>>>
>>> Hmm, that I don't know. I think that it should be a cardinality (not 
>>> minCardinality) restriction.
>>
>>
>> I also think it should  be a cardinality, and I don't remember anyone 
>> advocating minCardinality.
> 
> 
> You forgot :) We had a lengthy discussion about this.

Thanks for the reminder; you are right.  I remember now (although in my 
memory it seems more like a short discussion, for what that's worth). 
However, now that I'm not under the sway of your telecon eloquence ;-), 
I'm not sure I agree with your point anymore ...

> 
> If you interpret it as syntax (i.e., the *user specified* type) then a 
> cardinality could be appropriate. If it is the *actual type* (in the 
> sense that it should eventually resolve to the rdf:type of a value) 
> then, minCardinality is required. The understanding at the time of the 
> design was the latter.

I fully agree, of course, that a specific value of a parameter (at 
runtime) will normally have multiple types.  E.g., if input I1 is 
defined to have parameterType "http://animalkingdom.com/....#Racoon" 
then when #Rocky is provided as a particular runtime value of I1, #Rocky 
clearly has (at least) types ...#Racoon, ...#Mammal, and ...#Animal.

Note that #Rocky is *not* an instance of I1, in the OWL sense.  As you 
know, the relationship between I1 and a runtime value like #Rocky isn't 
made explicit in OWL-S (although various people, including you, have 
ideas about how to extend OWL-S to make it explicit).  What I mean is 
that there's no explicit property, like, say,
   runtime_value_of(#Rocky, #I1)
that relates these 2 things.

#Rocky *does* of course have to be an instance of ....#Racoon.  We know 
that (implicitly) because that's what our documentation says about how 
parameterType is supposed to be used.

What we are discussing here is possible values of instances of the 
property parameterType (like "http://animalkingdom.com/....#Racoon" in 
the above example).  As the authors of the OWL-S ontology, we can say 
what a particular value of parameterType means.  Why don't we just say 
that a particular value of parameterType is "a URI for a class 
description for the unique class that contains all possible values that 
can be taken by the relevant parameter at runtime".  Then, it seems to 
me, parameterType declarations would correspond to most people's normal 
intuition of what a parameter type declaration means.  And then a 
cardinality of 1 (which is also intuitive for most people here) would be 
valid.

What am I missing?  Would this approach break something?

< snip ... >

Cheers,
David

Received on Wednesday, 5 January 2005 22:56:23 UTC