W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re: RDF+Transformation = XHTML or is there sth like inverse GRDDL?

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 06 Jul 2007 11:52:19 +0100
Message-ID: <468E1EE3.1040309@hp.com>
To: Steve Harris <swh@ecs.soton.ac.uk>
CC: Jacek Kopecky <jacek.kopecky@deri.org>, Danny Ayers <danny.ayers@gmail.com>, al@jku.at, semantic-web@w3.org



Steve Harris wrote:
> 
> On 4 Jul 2007, at 13:18, Jacek Kopecky wrote:
> 
>> Hi Andreas, Danny, all,
>>
>> I've tried SPARQL+XSLT, not to HTML, but to app-dependent XML.
>> My experience was that it's a limited approach. In this longish post
>> I first talk about my experience, then about my XSLT-based solution  
>> and
>> then about what I would see as an optimal solution.
>>
>> So the idea was: use SPARQL SELECT to get the data that you need  
>> and put
>> them in the XML variable binding results table (which may have been  
>> the
>> wrong choice), then use XSLT to transform that to the target XML.
>> The necessary SPARQL results table vocabulary, however, made the XSLT
>> basically write-only, you wouldn't want to read or maintain such a
>> beast.
>>
>> Another problem is with repeating structures in the target XML. Let's
>> say I want to create something like this intentionally trivial XML:
>>
>> <catalog>
>>   <product id="1">
>>     <part name="wheel"/>
>>     <part name="engine"/>
>>     <part name="chassis"/>
>>   </product>
>>   <product id="2">
>>     <part name="antenna"/>
>>     <part name="receiver"/>
>>   </product>
>> </catalog>
>>
>> The SPARQL could be
>>
>> SELECT ?prodid ?partname
>>> WHERE { ?prodid rdf:type Product ;
>>>                 hasPart ?partName . }
>> But the results table will be:
>>
>>         1  wheel
>>         1  engine
>>         1  chassis
>>         2  antenna
>>         2  receiver
> 
> I've run into this problem a lot as well. I can imagine a SPARQL  
> syntax extension like:
> 
> SELECT DISTINCT ?prodid ?partname
> WHERE { ?prodid rdf:type :Product ;
>                  :hasPart ?partName . }
> GROUP BY ?prodid
> 
> which could return something like:
> ...
> <result>
>    <binding name="prodid"><literal>1</literal></binding>
>    <binding name="partname">
>       <literal>wheel</literal>
>       <literal>engine</literal>
>       <literal>chassis</literal>
>    </binding>
> </result>
> ...
> 
> If you have it in that form it's a lot easier to do the kind of XSLT  
> transforms we're talking about.
> 
> That sort of trick may catch SQL users off-guard, it might be worth  
> writing ARRAY(?partname) or similar. I think it would be pretty handy  
> given the random and surprising cardinality that RDF predicates often  
> have in the wild though.
> 
> - Steve

Maybe it would be better to have something like "CLUSTER BY" to control the 
output representation and leave GROUP BY for the expected SQL-ish grouping 
because that extends to aggregation.  CLUSTER BY with be lists of variables to 
generate the hierarchy as a subset of SELECT.  Whether multiple clusters make 
sense, I don't know.

It also looks quite like nested table attributes so an approach with nested 
queries make a general approach as well.

SELECT DISTINCT ?prodid ?partname
WHERE { ?prodid rdf:type :Product .
          SELECT ?partname { ?prodid :hasPart ?partName }
       }

     Andy
Received on Friday, 6 July 2007 10:52:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:58 UTC