Re: [OWL-S] DLization of 1.1

On Apr 7, 2004, at 8:03 AM, Daniel Elenius wrote:

>
>>> 2) OWL DL doesn't allow renaming built-in rdf, rdfs or owl classes 
>>> or properties[1], so they have to be called something other than 
>>> List/first/rest.
>>
>>
>> They need to be called something other than *rdf*:List/first/rest. 
>> Which they are. That was the whole point :)
>>
>> Replace the content of the  &shadow-list; with the rdf namespace and 
>> watch the WonderWeb validator moan.
> Oh, sorry.

No problem.

>>> Is this list construct going to be used in OWL-S or is the issue not 
>>> settled?
>>
>>
>> It's a stop gap that makes the current OWL-S DL compatible. It's 
>> really intended only for the syntactic uses you see in the current 
>> ontologies. I am working on other list vocabulary that could be used 
>> to model, say, parameterTypes, but it gets ugly, quick.
>>
> Tell me about it. I tried replacing rdf:List with my own owl:List 
> similar to yours. Populating the lists while not being able to use 
> rdf:Collection to group elements quickly becomes ugly, overly verbose, 
> and error-prone:

My current thought is to add some decoration to RDF/XML that would let 
an XSLT script know which parseType=Collection to covert. Since we'll 
want something like that for data value oneOfs anyway, maybe it'll get 
some traction.

The ugly part is you need to do a bunch a work to hand data valued 
lists.

> On the other hand, most services will probably be modeled using tools 
> anyway, so this may not matter much.

At least such a tool.

I need to set up equivalences to the builtins (in a separate ontology) 
for owl full compatibility.

> A different representation in OWL DL could be:

This is interesting, but, FWIW, I meant not an alt represenation of 
*lists* but of process sequencing and aggregation. My current handwave 
is to say we should somehow use the temporal properties before and 
after.

> <owl:Class rdf:ID="List>
> </owl:Class>
>
> <owl:ObjectProperty rdf:ID="listElement">
>  <rdfs:domain rdf:resource="#List"/>
>  <rdfs:range rdf:resource="ListElement"/>
> </owl:ObjectProperty>
>
> <owl:Class rdf:ID="ListElement">
> </owl:Class>
>
> <owl:DatatypeProperty rdf:ID="elementIndex">
>  <rdfs:domain rdf:resource="#ListElement"/>
>  <rdfs:range rdf:resource="&xsd;#NonNegativeInteger"/>
> </owl:DatatypeProperty>

Yep. A good trick. One we discussed. There was no consensus for 
anything new this round. I hope we make such a decision for the final 
version.

> <owl:ObjectProperty rdf:ID="elementValue">
>  <rdfs:domain rdf:resource="#ListElement"/>
>  <rdfs:range rdf:resource="&owl;#Thing"/>
> </owl:ObjectProperty>
>
> Instances would look like:
>
> <List>
>  <listElement>
>    <ListElement>
>      <elementIndex 
> rdf:datatype="&xsd;#NonNegativeInteger">0</elementIndex>
>      <elementValue> some value </elementValue>
>    </ListElement>
>  <listElement>
>    <ListElement>
>      <elementIndex 
> rdf:datatype="&xsd;#NonNegativeInteger">1</elementIndex>
>      <elementValue> some other value </elementValue>
>    </ListElement>
> </List>
> Which is arguably a lot nicer than what you get with a home-made 
> linked list at least...

Vectors rock :)

> I have another question: How will parameter instances look in OWL-S 
> 1.1? In 1.0, we have things like this:
>
> <process:Input rdf:ID="CongoBuySignInInfo">
>  <process:parameterType rdf:resource="#SignInData"/>
> </process:Input>
>
> So, Inputs are instantiated, and the parameterType property points to 
> a *class*, which is of course OWL Full (classes-as-instances* are not 
> allowed by OWL DL). How will this look in OWL-S 1.1

I sent mail recently to the list discussion a solution. That solution 
is now in the 1.1 files.

See:
	http://lists.w3.org/Archives/Public/public-sws-ig/2004Mar/0055.html

Basically, parameterType is now a DatatypeProperty to a URI which 
identifies a type (could be an owl:Class, could be a datatype, could be 
a java type, who knows).

This just *avoids* the whole classes as instances or datatypes as 
classes issue, entire. At least for the moment.

Type checking now really does require writing some special code to 
extract the the proper type given the uri. I was tempted to add some 
stuff indicating the type system, but it's a bit hairy at the moment 
how this will be used. I hope we will be able to replace this hack with 
a good axiomiztion (or at least some techniques for encoding 
parameterTypes), but it's unclear ;)

Suggestions welcome. My last one involved putting restrictions on 
possible execution traces which tends to involve a lot more machinery. 
It's also unclear what *sort* of type checking/inference is 
wanted/possible.

Cheers,
Bijan Parsia.

Received on Wednesday, 7 April 2004 08:45:30 UTC