Re: RDF, XML, XSLT: Grit

Fair enough then, different use case than I had in mind then, I'd say.
I understand that you don't deal with big ammounts of native RDF data here, 
which was more what I had in mind.
 
>    (IIRC your XSPARQL also uses the SPARQL Query Results format internally.  )

Our current (native) implementation does, but we are thinking of improving that,
still, this is an internal implementaiton issue, independent of the overall query, 
that is, the language itself does not rely on SPARQL's result format.

best,
Axel



On 20 Jan 2010, at 12:52, Christoph LANGE wrote:

> Hi Axel,
> 
> 2010-01-20 11:45 Axel Polleres <axel.polleres@deri.org>:
> > reading the thread with interest. If I understand correctly most of these
> >  approaches Grit, RXR, etc only provide normalisation, which in my opinion
> >  is only ONE part of the story in making existing RDF data amenable to
> >  XSLT/XQuery transformations.
> >
> > What it doesn't address is that probably big (and increasingly with the
> >  adoption of SPARQL) ammounts of RDF data are residing in RDF stores... you
> >  don't want to dump that whole data into RDF/XML first and then query it
> >  with XSLT/XQuery if a SPARQL interface is already available, do you?
> >
> > To this end we have developed a combined query- and transformation language
> >  called XSPARQL [1,2,3] which should address this drawback. ...
> 
> Theoretically, I fully agree.  Practically, I partly agree.  I have been
> following the development of XSPARQL, and I am looking forward to it becoming
> more widely supported.  Using SPARQL for RDF queries and XQuery for XML
> queries is definitely my preferred division of responsibilities.  But it is
> not always possible for technical reasons.
> 
> The setting in which I'm currently using RXR is an XML database that natively
> supports XQuery (http://trac.mathweb.org/tntbase/, based on Berkeley DB XML).
> From this database, you can retrieve XML documents as they are, or, for
> certain languages supported by the system, you can also retrieve documents
> rendered to HTML via XSLT.  Now we wanted to enrich that HTML output by RDFa.
> The developer of TNTBase was not in favor of installing a triple store and
> SPARQL endpoint _only_ for the purpose of providing the RDF that was to be
> integrated into the HTML output as RDFa, as that is currently only a minor
> goodie, not the core feature of the system.  On the other hand it was not a
> big deal in our setting to make the RDF data available as RXR, and to add some
> code to the XSLT that queries RXR and transforms it into RDFa annotations.
> 
> I think what makes the difference in my setting is
> 
> 1. that the RDF→XML transformation (here: providing RDF as RXR) is not a
>    superfluous roundtrip.  Even if we could obtain the RDF from a SPARQL
>    endpoint, we would eventually have to convert it to some XML representation
>    (e.g. SPARQL Query Results) in order to feed it into the rendering XSLT.
>    (IIRC your XSPARQL also uses the SPARQL Query Results format internally.  )
> 2. that RXR is perfectly suitable for the task:  We do not do high-level
>    queries, but only retrieve predicates and objects for a given subject.
>    This is perfectly feasible with RDF represented as some normalized XML.
> 
> >  is it really normalized RDF/XML that we want or don't we rather want to
> >  query RDF directly with SPARQL and XML with XQuery/XSLT?
> 
> So my conclusion is that direct queries are preferable theoretically, as well
> as in many practical applications, but that there will always be other
> practical applications, where it is more suitable to query normalized RDF as
> XML.
> 
> Cheers,
> 
> Christoph
> 
> --
> Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
>

Received on Wednesday, 20 January 2010 14:51:45 UTC