Re: OWL-S: Parameter modeling

On Jul 2, 2004, at 11:05 AM, Stephane Fellah wrote:

>
> Hi,
>
> I have a question related to parameter modeling in OWL-S. Prior to  
> version 1.0, parameter,input,output,precondition,effect where modeled  
> as rdf:Property, then there have been changed to become owl:Class.

Yes.

>  I cannot find the rationale of the change in the documentation of the  
> ontology and in the mailing list.

There are a lot of features of a parameter that need to be modeled  
(name, type, parameterType, binding, etc.). Given that we now have  
processes as instances and a pattern of modeling the features of a  
process as linked individuals, the move is natural.

It's also probably necessary to be OWL-DL friendly.

> I have found the former version more practical, because the range of  
> the parameter (called parameterType in OWL-S 1.0,1.1) can naturally be  
> expressed as the range of the property.

Yes, that's convenient, however, largely insufficient in the long haul.  
(Parameters are somewhat different than properties.) Also, that doesn't  
work for processes as instances, I believe, at least no happily.

> A parameter description should have a number of properties: unique  
> name,  description, type (datatype, or a owl:class), and optionally a  
> set of constraints (enumeration of single values, interval with  
> specific resolution, or a mix of both). You can think a parameter as  
> an OLAP dimension, in dimension modeling.

er...this pushes us to classes, I think.

> To express the properties of image scale operator (process),you may  
> describe the scaleX parameter the following way:
>
> <owl:DatatypeProperty rdf:id="scaleX">
>     <rdfs:subPropertyOf  
> rdf:resource="http://www.daml.org/services/owl-s/0.9/ 
> Process.owl#parameter"/>
>     <rdfs:domain rdf:resource="http://www.foo.com#ScaleOperator"/>
>     <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
>     <parameterName>scaleX</parameterName>
>     <description>scale in X</description>
> </owl:DatatypeProperty>

The last two properties, in OWL-DL, would have to be  
"AnnotationPropertie" and thus have no meaning to a reasoner. You  
cannot classify properties based on such metaproperties (in OWL DL).  
Etc. Having lots of subproperties like this (especially with global  
restrictions) also strikes lots of people as ugly or unfortunate. In  
certain circumstances it can make reasoning much more difficult (and  
certain can avoid the sweet spot of a lot of currently optimized  
implementations).

> You can declare parameterName in the following way:
>
>  <owl:DatatypeProperty rdf:ID="parameterName">
>     <rdfs:domain  
> rdf:resource="http://www.daml.org/services/owl-s/0.9/ 
> Process.owl#parameter"/>
>     <rdfs:range  
> rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
>   </owl:DatatypeProperty>
>
>
> When a operator is used, you can directly use the parameter property:
>
> <ScaleOperator rdf:id="myScaleOp">
>    <scaleX>1.43</scaleX>
>    <scaleY>1.43</scaleY>
> </ScaleOperator>

But this binds to a particular value. I don't understand how you would  
model variable binding.

> I have found this approach much more readable than the current  
> approach used in OWL-S 1.0 and 1.1. Moreover it can bind nicely to  
> Process Object.
>
> Is there any problem for OWL-S to use this approach. Are we in 2nd  
> order predicate logic here ?

Not necessarily. Check out the RDF Semantics, the LBase document, and  
the RDF compatible model theory in the OWL Syntax and Abstract Syntax  
document. You might also look at hilog.

> Does the existing OWL inference engine work this way ? Are we still in  
> OWL-DL ?

Some for the former, depends for the latter.

> I would like you to discuss the pro and cons of each approach. Thanks  
> in advance.

Part of our current approach is to be somewhat consistent in our  
modeling style. Reifying certain sorts of relations (like parameter)  
has advantages in a language with inexpressive relation modeling  
constructs. It's a bit like building and abstract syntax tree.

Cheers,
Bijan Parsia.

Received on Friday, 2 July 2004 11:24:58 UTC