W3C home > Mailing lists > Public > public-powderwg@w3.org > April 2008

Semantics question (was Re: XSLT question)

From: Phil Archer <parcher@icra.org>
Date: Tue, 22 Apr 2008 10:13:16 +0100
Message-ID: <480DAC2C.1080503@icra.org>
To: Public POWDER <public-powderwg@w3.org>

OK, I'm still struggling with this.

Let me start with a question and add in some detail later.

is this possible (I'm pretty sure the answer's no) - in which an RDF 
Description block is made the sub class of an OWL class?

<rdf:Description rdf:nodeID="descriptorset_1">
   <ex:colour>red</ex:colour>
   <ex:shape rdf:resource="&ex;square" />
</rdf/Description>

<wdr:iriset rdf:nodeID="iriset_1">
   <owl:Restriction>
     <owl:onProperty
        rdf:resource="http://www.w3.org/2007/05/powder#regex" />
     <owl:hasValue>\:\/\/([^\:\/\?\#\@]+\.)?(example\.com)(:([0-9]+))?\/
     </owl:hasValue>
   </owl:Restriction>
</wdr:iriset>

<owl:Restriction>
   <owl:onProperty
     rdf:resource="http://www.w3.org/2007/05/powder#hasIRI"/>
   <owl:someValuesFrom rdf:nodeID="iriset_1"/>
   <rdfs:subClassOf rdf:nodeID="descriptorset_1"/>
</owl:Restriction>

If so we need to update some DR-S examples but basically that's nice and 
easy.

If not... we have a problem.

Try this

<descriptorset>
   <icra:na>1</icra:na>
   <icra:vj>1</icra:vj>
   <bbfc:rating ref="http://www.bbfc.org/1997/#12" />
</descriptorset>

What's the S version? The ICRA stuff is easy - property value 
restrictions, OK, but the external reference?

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Class rdf:resource="http://www.bbfc.org/1997/#12" />
     ...
   </owl:intersectionOf>
</owl:Class>

The problems I see are that:

1. We've lost some data, i.e. the bbfc:rating predicate (does that matter)

2. In the XML we're referring to an RDF class as if it's an XML element.

3. If we say that the external referent must be an XML element that 
doesn't help us because we don't know the URI of the equivalent RDF class

Phil





Smith, Kevin, VF-Group wrote:
> To answer the easy question:
> 
>>> Does the output of an XSLT have the same URI as the input?
> 
> Not always, XSLT processors may change the output file name (and hence
> the output URI will differ). Requesting an IRI/URI *may* result in the
> XSLT output being sent. However XSLT (or many XSLTs) may be pipelined in
> order to create the output, which confuses things further. 
> 
> -----Original Message-----
> From: public-powderwg-request@w3.org
> [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
> Sent: 21 April 2008 14:35
> To: Public POWDER
> Subject: Re: XSLT question
> 
> 
> OK, can we resolve this on the call in a couple of hours please?
> 
> And here's a related question. Does the output of an XSLT have the same
> URI as the input?
> 
> I ask because we might have things like this:
> 
> <descriptorset xml:id="descriptorset_1">
>    <ex:property1>value</ex:property1>
>    <ex:property2 ref="http://www.example.org/descriptions.rdf#Class" />
> </descriptorset>
> 
> Which transforms into ... what? This?
> 
> <owl:Class rdf:nodeID="descriptorset_1">
>    <owl:intersectionOf rdf:parseType="Collection">
>      <owl:Restriction>
>        <owl:onProperty rdf:resource="&ex;property1" />
>        <owl:hasValue>value</owl:hasValue>
>      </owl:Restriction>
>      <owl:Restriction>
>        <owl:onProperty rdf:resource="&ex;property2" />
>        <owl:hasValue
>        rdf:resource="http://www.example.org/descriptions.rdf#Class" />
>      <owl:Restriction>
>    <owl:intersectionOf>
> </owl:Class>
> 
> Which looks wrong and, well, suppose
> http://www.example.org/descriptions.rdf#Class is a POWDER descriptor
> set, we now have an 'RDF resource' of something that probably isn't RDF.
> 
> Which, I think _might_ mean that we have to put some very tight
> restrictions on what can be in the descriptor set - i.e. you can only
> have string literal values. You can refer to an externally defined
> descriptor set /instead/ of a local one, i.e.
> 
> <descriptorset ref="some_other_descriptor_set" />
> 
> but you can't mix and match.
> 
> Alternatively, maybe we need to devise a system for pointing separately
> to the POWDER and POWDER-S versions of the external file? Which sounds
> horrible.
> 
> The original idea was that the descriptor set would be arbitrary RDF/XML
> (as long as you don't create any blank nodes) but we seem to have gone
> passed that, am I right? I think the original idea (discussed in Athens)
> was that we'd have
> 
> <descriptorset xml:id="descriptorset_1">
>    <ex:property1>value</ex:property1>
>    <ex:property2
>       rdf:resource="http://www.example.org/descriptions.rdf#Class" />
> </descriptorset>
> 
> i.e. using rdf:resource, not ref, and we'd have this hybrid of XML and
> RDF/XML. In this case the transformation for the descriptor set is "copy
> verbatim" - but this ends up with an RDF description, not an OWL class,
> which I think is the problem.
> 
> Hmmm...
> 
> Phil
> 
> P.S. About to pop out for a while, back _just_ before the call.
> 
> 
> 
> 
> 
> Stasinos Konstantopoulos wrote:
>> My suggestion in this, and similar, situations is to never try to get 
>> smart with the XSLT transforms, because that's an unnecessary 
>> complexity that is, sooner or late, going to come back and bite us. 
>> Gratuitous unions and intersections do no harm, and make it easier to 
>> validate the XSLT as there are fewer cases and combinations to check.
>>
>> A human directly writing in POWDER-S is welcome to optimize it, we 
>> never promised that it can get transformed into POWDER/XML anyway.
>>
>> s
>>
>>
>> On Mon Apr 21 12:50:28 2008 Phil Archer said:
>>
>>> I guess this is mostly for Kevin but anyone's free to chime in ;-)
>>>
>>> [...]
>>>
>>> Assuming this is right, here's the question - can the XSLT work out 
>>> whether or not the unionOf is necessary so that where there is only 
>>> one IRI set (i.e. 99% of the time) it can drop the unionOf 
>>> properties? Or will we often have a union of 1? The same goes for the
> 
>>> IRI sets themselves where in many examples we have intersections of a
> 
>>> single property restriction.
>>>
>>> Basically I guess it's a trade-off between processing complexity and 
>>> redundant data. So which wins? (and remember, it's 12st April 
>>> already...)
>>>
>>> Phil.
>>
Received on Tuesday, 22 April 2008 09:13:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:12 GMT