W3C home > Mailing lists > Public > public-sws-ig@w3.org > March 2004

[OWL-S] Parameter Types

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sun, 28 Mar 2004 21:22:40 -0500
Message-Id: <F41D721E-8127-11D8-8F97-0003936A0B26@isr.umd.edu>
To: public-sws-ig@w3.org

We're trying to settle the issue of how to represent the type of a 
paramter of a process.

Well, more precisely, we're trying to come up with something we all can 
live with for the time being :)

One constraint we are trying to obey is staying in OWL DL. This is a 
bit trickier than one might think as:
	We want inputs to be either XML Schema Data values *or* OWL Classes
	Our Process as Instances formulation makes it very natural to relate a 
parameter to
		a class (or datatype) which is its parameterType by a property 
called, say, 		parameterType

Another constraint is that we don't have a theory of execution traces 
at the moment, nor a way of relating those traces to our current 
process models. This makes things a bit trickier (since parameterTypes 
constrain the *actual* runtime bindings of steps in an execution 

Our current representation: A Process's parameters are encoded as 
instances of Parameter, itself soon to be a subclass of Variable 
(cribbed from SWRL, I understand). Right now we have a parameterType 
property hanging off Parameter. My proposal is that we make this a 
DatatypeProperty with range xsd:anyURI (which is a builtin OWL 
datatype). We will specify (in natural language) that this URI should 
name a type constraint on the input, with OWL Classes or XSD datatypes 
being the standard form. (We'll leave unspecified what happens if it 
names an OWL individual...OWL DL respecting systems might through a 
type error, while OWL Full systems might infer that it is also a 
class). An OWL DL respecting system will have to take care to ensure 
that the appropriate properties are used in the execution trace (i.e., 
DatatypeProperties for data, etc.).

The Process ontology would be changed as so:

<owl:DatatypeProperty rdf:ID="parameterType">
   <rdfs:domain rdf:resource="#Parameter"/>
   <rdfs:range rdf:resource="&xsd;anyURI"/>
<!--	I generated an amusing typo here: I wrote "rdfs:rage" for 
	Make of it what you will :)-->


This is very much a compromise position, likely to be unpalatable to 
most. The biggest authoring imposition I see for it is the need to use 
rdf:datatype, but hey, if you have cardinality constraints, you already 
are using them. Having to put a datatype uri on every typed literal is 
way annoying, though.

It's a bit crimpy for OWL Fullers, because they won't be able to infer 
some things they may have wanted to infer. But I've not seen a good set 
of axioms for parameterType yet, so I'm inclined to not-worry. 
Presumably, any reasonable OWL Full system will be able to deal with 
this representation just fine. Given the difficulty of doing data 
*validation* in OWL like languages, it's all a bit moot anyway.

One alternative would be to have a richer representation at the end of 
this property. E.g., a Type object which might specify the type system 
as well, and perhaps some other constraints (e.g., to help solve the 
Decker problems by specifying soem closure conditions on the kb). I 
suspect this should be done now rather than later, although it wouldn't 
be *too* big a change.

Feedback desired.

Bijan Parsia.
Received on Sunday, 28 March 2004 21:23:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:12 UTC