Re: Semantics question (was Re: XSLT question)

Let me try and answer my own question (because it's doing my head in and 
I'd like to be able to think about something else at 3 o'clock tomorrow 
morning). For this I'm using ICRA and the British Board of Film 
Classification (BBFC)* as examples.

I think this actually goes to the heart of what POWDER is. If the idea 
is that, for a given candidate URI we return triples then this is 
probably right:

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

Note the use of rdf:resource.

A POWDER processor can turn out

<candidateURI> icra:na 1.
                icra:vj 1.
                bbfc:rating <http://www.bbfc.org/1997/#12>;

The chunk of RDF/XML that would become this in POWDER-S:

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&icra;#na" />
       <owl:hasValue>true</owl:hasValue>
     </owl:Restriction>
     <owl:Restriction>
       <owl:onProperty rdf:resource="&icra;#vj" />
       <owl:hasValue>true</owl:hasValue>
     </owl:Restriction>
     <*owl:Class* rdf:resource="http://www.bbfc.org/1997/#12" />
   </owl:intersectionOf>
</owl:Class>

So the ICRA descriptors (which have literal values) would become 
property restrictions on the OWL class. The BBFC rating becomes another 
class and the descriptor set is the intersection of all three.

The use of rdf:resource tells the processor that the referred to item is 
an RDF (or OWL) class and not another POWDER (XML) descriptor set. For 
that we'd use ref, i.e.

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

Now that becomes something different in POWDER-S because we're referring 
to something else that is a description but that is not an RDF or OWL 
class - it could be anything, hence this would become

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&icra;#na" />
       <owl:hasValue>true</owl:hasValue>
     </owl:Restriction>
     <owl:Restriction>
       <owl:onProperty rdf:resource="&icra;#vj" />
       <owl:hasValue>true</owl:hasValue>
     </owl:Restriction>
   </owl:intersectionOf>
   <*rdfs:seeAlso* rdf:resource="http://www.bbfc.org/1997/#12" />
</owl:Class>

This class still has the ICRA property restrictions but now just says 
'take a look over there as well' but the BBFC rating is not part of the 
actual description.

This raises issues over whether people will 'get' the difference between 
ref and rdf:resource but that's life.

WDYT?

Phil.

* BBFC does not have an RDF vocabulary for its classification but you 
never know, a member of their Consultative Council may yet help them do 
this ;-). http://www.bbfc.org.uk/structure/structure10.php

Phil Archer wrote:
> 
> 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 16:58:47 UTC