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

Re: XSLT question

From: Phil Archer <parcher@icra.org>
Date: Mon, 21 Apr 2008 14:35:28 +0100
Message-ID: <480C9820.9020904@icra.org>
To: Public POWDER <public-powderwg@w3.org>

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:property2 ref="http://www.example.org/descriptions.rdf#Class" />

Which transforms into ... what? This?

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
       <owl:onProperty rdf:resource="&ex;property1" />
       <owl:onProperty rdf:resource="&ex;property2" />
       rdf:resource="http://www.example.org/descriptions.rdf#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 

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">
      rdf:resource="http://www.example.org/descriptions.rdf#Class" />

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.



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 Monday, 21 April 2008 13:36:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:03 UTC