Re: [OWL-S] DLization of 1.1

> 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.
>
Let me see if I get this right. Are you suggesting that OWL-S files are 
first written using something similar to parseType=Collection plus some 
extra decoration, and then converted using XSLT to a representation that 
is proper OWL DL?

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

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

An alternative would be to use "singleton" class instances, like so:

<owl:Class rdf:ID="SignInData">
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#TheSignInData"/>
  </owl:oneOf>
</owl:Class>


<process:Input rdf:ID="CongoBuySignInInfo">
 <process:parameterType rdf:resource="#TheSignInData"/>
</process:Input>


But I'm not sure if these inputs are intended to be instantiated or not. 
If they are, then this doesn't work. But it looks to me like we just 
want to point to a data _type_ rather than an instance _value_, in which 
case my suggestion would work, I think. This way of doing it means more 
semantic information in the model without a dedicated reasoner to 
extract the datatype given as a URI, as you designed it.

Unfortunately though, with my way of doing it, different kinds of 
parameterType are needed for datatypes and OWL classes, since it can't 
be both a DatatypeProperty and an ObjectProperty.

/Daniel

Received on Wednesday, 7 April 2004 09:08:18 UTC