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

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

which is not easily transformed with XSLT into the target structure. And
imagine that some repeating structures were embedded in <part>, one gets
an explosion of repeating data in the result.


So instead of using SPARQL+XSLT I decided to go the other common way -
serialize the RDF in a predictable way in an XML format and then use
XSLT on that. Because I like standards, the predictable format is a
subset of RDF/XML and the serialization is done with an XSLT step, a
pre-processor for the final, app-dependent XSLT.

Still, some of the XPaths in the final XSLT could be ugly, so I also
created a few XSLT functions (rx:*) to help. A resulting XSLT looks
something like this:

<xsl:template match="rdf:Description[rdf:type/@rdf:resource='http://example.com/#Product']">
  <product id="{rdf:about}">
    <xsl:for-each select="//rdf:Description[rx:references(current()/hasPart, .)]">
      <part name="{rdf:about}">
    </xsl:for-each>
  </product>
</xsl:template>

The whole thing is described in [1], section 3, and I call it RDFXSLT
(yes, no imagination there). I'm working on a much better description of
the whole thing, btw, the current doc is the first complete draft. 8-)
All you need to run it is XSLT2 processor, I've tested it with Saxon.
This eliminates the need for other, non-standards-based tools (which may
be much better solutions in some environments).

[1] http://www.wsmo.org/TR/d24/d24.2/v0.1/20070412/rdfxslt.html


Anyway, this is not an optimal solution, as the XPaths still aren't
quite natural. I like Fresnel and especially FSL, but it doesn't seem
it's on the standards track (please correct me if I'm wrong); 
myself I was thinking about something like this in a SPARQL extension,
which might be easier to standardize than FSL:

CONSTRUCTXML
<catalogue>
  <product id="{?prodid}">
    {CONSTRUCTXML
      <part name="{?partname}"/>
     WHERE { ?prodid hasPart ?partName }
    }
  </product>
</catalogue>
WHERE { ?prodid rdf:type Product }

You see that it has to be recursive and that variable bindings have to
be passed into the recursion, but that's about all the complexity in
this extension. Anybody interested in pursuing this with me? 8-)
BTW, this is somewhat similar to Keith's templates, I'd note, but again,
perhaps much easier to standardize.

Thanks for reading this far,
Jacek


On Wed, 2007-07-04 at 12:03 +0100, Danny Ayers wrote:
> Hi Andy,
> 
> For the sake of (nearer to) completeness, I'll add SPARQL+XSLT to the
> list. Used directly there's the possibility of generic representation
> from something like SELECT ?s ?p ?o as well as domain-specific stuff
> (e.g. FOAF to hCard [1]).
> 
> One drawback is that the source vocabulary, the SPARQL and the
> resulting HTML (or whatever) are quite tightly coupled. But it is
> possible to insert another layer of indirection separating data and
> (document) presentation thus:
> 
> 1. SPARQL CONSTRUCT maps domain-specific source RDF (v1) into a graph
> using a generic, more document-structural/presentation-oriented
> vocabulary (v2)
> 2. fairly generic SPARQL against v2 produces (/filters) required data
> 3. fairly generic XSLT againsts result of 2. yields final document
> 
> This two-phase querying allows non-domain-specific reuse of the
> doc-oriented SPARQL & XSLT of 2. & 3.
> 
> When I was playing with this approach I hacked a very simple
> structured report vocabulary (I forget exactly, it had something like
> Sections & Details) which worked surprisingly well for little effort,
> being able to look after the data-doc mapping and doc presentation
> separately simplified changes. The only real pain I had was in
> grouping results in XSLT 1.0 - but XSLT 2.0 can alleviate that.
> 
> I've a feeling this approach (or something very similar) could be used
> to implement Fresnel, but I've not had chance to look closely.
> 
> Cheers,
> Danny.
> 
> [1] http://dannyayers.com/2006/07/04/foaf-to-hcard-via
>

Received on Wednesday, 4 July 2007 12:24:54 UTC