Re: [owl-s] Parameter and parameterType

On Aug 3, 2004, at 6:28 PM, Tor Arne Kvaloy wrote:

> Greetings to all believers of the Semantic Web,

We hope to be the beliefs, not the believers. :)

>>> I find it also strange that the API provides a getType() method, 
>>> while
>>> in
>>> the OWL-S ontology the parameterType is specified with a
>>> minCardinality of
>>> one, meaning that there can be more than one of the property.
>>>
>>> How can it make sense to have more than one parameterType if they are
>>> not
>>> given unique names?
>>
>> If they aren't given names at all? Oh, I see.
>>
>> paremeterType is a property relating a parameter and its type. So, the
>> *relation* is parameterType, but the *value* will be distinct classes.
>>
>>> Or, is it really so that each parameter is supposed to only have one
>>> parameterType?
>>
>> No. Just consider that all owl classes are subclass of thing. This
>> restriction would force you to only have type owl:Thing (and event 
>> that
>> isn't correct, since you *will* belong to an infinite number of 
>> unnamed
>> classes)
>
> I don't see how properties like parameterType can be given *value*, 
> unless
> new properties are defined that are subProperties of the parameterType

I don't *think* you mean you don't see how particular "instance" of 
parameterType can be given a value. But the *point* of parameterValue 
is relate a parameter to a type, and, given the current ontology, we 
can do that, indeed, do it in a sensible way. It does require extra-OWL 
checking, but that's true for most owl-s semantics.

This discussion belongs on the sws-ig mailing list at the W3C. That's 
where generic discussion of OWL-S takes place.


> property defined in OWL-S ontology (please see code in my previous 
> email).

That code was not, imho, doing what you hoped it to do. It *could* do 
that, but it is certainly contrary to the intent of the specification 
and the general style of the OWL-S ontologies. See serviceParamteres.

parameterType is intended to be a relatively generic property. I.e., 
all paramters should have a paramater type the *value* of which is a 
uri denoting a type.

So, your example is, in fact, broken, as it &xsd; string isn't 
compatible with &xsd;anyURI (I believe).

Furthermore, I don't think that style is a good one. If you want a 
specific *type* of xsd:string, you should define the appropriate type 
(e.g., Word subType of xsd:string). Then parameterType relates to 
*that* (no need for a subproperty). If you want to make a class of 
inputs all of which are constrained to a certain type, then use a local 
property restriction on propertyType.

> Could you please provide me with an example of how this can be done?

Either I am correct about what you are trying to model in which case I 
believe my description above suffices, or I am not, and I have no idea 
what you are trying to accomplish. But here is your example:

<process:Input rdf:ID="TranslateWord">
       <process:paramterType rdf:datatype="&xsd;anyURI" 
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</process:Input>

If you want a more specific datatype, you need to create a derivation 
of that simpleType, and we need an URI for it. There is currently and 
effort between the Semantic Web Best Practices working group and the 
XML Schema working group to provide canonical URIs for user create XML 
Schema types. OWL-S will adopt this solution.

For owl classes, it's clearly easier. Just make sure it has a uri and 
pop it in there.

>  And
> that OWL-S API supports.
>
> None of the the examples I have seen
> (http://www.mindswap.org/2004/owl-s/services.shtml), define
> parameters(input/ouput) with more than one parameterType property.

I thought it was clear from my last post, but if you define a 
paramterType that is a subtype of ANYTHING, or you have a types system 
(like OWL) where you can have all sorts of equivalences and derivations 
of type, then you can, in principle, never, or only rarely have only 
one type. I.e., parameterType isn't "most specific type".

Hmm. It's not most general type, also, though that's perhaps a more 
useful notion.

What's still unspecified is whether multiple explicit types defines an 
implicit union. It could.

There is trickiness here, since it is the parameter's *values* that are 
members of the specified type. So we should look at parameterType as 
the constraint, and there's only one specified constraint. Huh.

So perhaps the only motivation is unions, which probably should be 
handled by the type system until there is specific contrary feedback.

Cheers,
Bijan Parsia.

Received on Wednesday, 4 August 2004 04:57:06 UTC