Re: [OWL-S] Parameter Types

Bijan Parsia wrote:

> 
> 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 trace).
> 
> 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 
> "rdfs:range".
>     Make of it what you will :)-->
> </rowl:DatatypeProperty>

This all seems fine to me.

[aside: Would you like me to keep the comment about "rdfs:rage" in the 
new version of Process.owl?]

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

I don't find it annoying.  I mean, let's face it, we've clearly left 
behind the idea that OWL-S (or OWL ontologies in general) are going to 
be readable, and the idea that people are going to spend much time 
directly editing the XML/RDF serialization.

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

Personally I also don't find this to be a significant concern (that is, 
I agree with the not-worry position), because I think it's pretty 
inevitable that type-checking, validation, and other kinds of reasoning 
about parameter types will rely on special-purpose code anyway.  (This 
is not to say that DL reasoning won't be part of that picture, though.)

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

Yes, any progress on this would be excellent, but since it's a fairly 
large design space (I think) and we haven't spent much time on it yet, 
I'm OK with proceeding to our next release without it.

Thanks,
David

> 
> Feedback desired.
> 
> Cheers,
> Bijan Parsia.
>

Received on Tuesday, 30 March 2004 21:19:24 UTC