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