Emmanuel Pietriga wrote:
> Stefano Mazzocchi wrote:
>
>> These are random comments on Section 2.1 of the current paper's working
>> draft, sent here for archival and for triggering further discussion.
>
>
> Also archiving my reaction to these comments.
>
>
>> - xslt over RDF/XML is always possible, it's just unberably hard and
>> error prone, due to the XSLT-unfriendly nature of RDF/XML.
>>
>> - "conceptually wrong" is a little big too strong, use "conceptually
>> defective"? A great example is the fact that rdf:type="blah" can become
>> the element name, modelling this in XPath is extremely hard.
>
>
> I really feel strongly against this RDF/XML+XSLT as a general approach
> for transformaing RDF. That's why I put "wrong". But you're right,
> that's probably too strong... The example is a good one and we should
> probably cite it. But it is more an illustration of the point above
> (unbearably hard) than of this one (conceptually defective).
As posted already, take a look at Jacco's paper at
Jacco van Ossenbruggen, Lynda Hardman, and Lloyd Rutledge. Combining
RDF Semantics with XML Document Transformations. In: International
Journal of Web Engineering and Technology (volume 1, number 4), 2005
Note: to be published, based on
http://ftp.cwi.nl/CWIreports/INS//INS-E0303.pdf .
Jacco has addressed these same (I think?) problems not by throwing XSLT
away but instead by determining the minimalized extensions needed for
XSLT. We use the Xalan's XSLT parser's extension for Java calls to call
the Sesame RQL query engine, which package the query returns in
table-like XML. We then use Xalan's node-set() XSLT function to hold
these returns and make then available for XSLT select attributes and
other XSLT constructs. From then on, pure, old-fashioned XSLT does the
rest. This demonstrates that XSLT for RDF is feasible and readily
implementable with current technology, making both "wrong" and
"unbearably hard and error prone" strong exaggerations. Furthermore,
Jacco and I have applied this technology quite a bit with the Noadster
semantic browser. It's not magic, and has a few quirks (mostly at a low
technical level, not at the general model level), but I found it to work
as well as most technical solutions. Both the paper(s) and Noadster show
you can make a tree from a graph. A general model and architecture and
readily available tools exist for it. In our approach, the RDF query
returns appear in an XML table that enables XSLT to process it. Output
hierarchical structure comes from the hierarchy of
<apply|call-template(s)> with their select attributes selecting from the
XML table. Output XML sequence comes from our frequent use of
<xsl:sort>. Thus the (sorted) tree from a graph.
The key point is that you don't have to XSLT the general, entire XML
serialization for the whole repository. You can query for a subset, and
this query can control the XML generated that is input to XSLT. Then
XSLT can further select, as well as group and sort, this input XML.
Received on Tue Apr 26 2005 - 11:11:42 EDT