Re: RDF, XML, XSLT: Grit

Hi Niklas,

we published a paper about RDF syntax normalization using XML validation in the workshop Semantics for the Rest of Us at ISWC2009. In this paper we describe a method that re-uses existing standards creatively in order to provide a guaranteed serialization of an RDF graph that can again be used easily with widely spread XML tools and techniques like SAX, DOM, or XSLT. ( http://www.aifb.kit.edu/web/Inproceedings3010/en )
At the moment we don't have the time to do further research in this area. If you like you can continue our work.

Regards,

Frank


-- 

Karlsruhe Institute of Technology (KIT)
Institut AIFB

Dipl.-Inform.Wirt Frank Dengler
Research Associate

Englerstr. 11
Building 11.40
76131 Karlsruhe, Germany

Phone: +49 721 608 - 6584
Fax: +49 721 608 - 6580
frank.dengler@kit.edu
www.kit.edu

KIT – University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association







Am 19.01.2010 um 01:23 schrieb Niklas Lindström:

> Hi Reto!
> 
> I have looked at some RDF/XML-normalizers before, but in all honesty I
> haven't tested R3X-transform very extensively. I have taken some care
> in assuring that the Grit XSLT handles very "raw" RDF/XML -- in my
> case using the "non-pretty" serializer of Sesame (on a graph
> consisting of multiple RDFS and OWL vocabularies). I have also tested
> it on the output of RDFLib. Remaining is to try it out extensively on
> all kinds of RDF in the wild, such as SPARQL construct results, and
> feeds of RDF/XML (see also about Atom below). The relative merits have
> yet to be assessed.
> 
> In terms of features, it certaibly groups by subject, normalizes type
> statements etc. Predictability is quite paramount. The current XSLT
> takes some rudimentary care of e.g. @xml:base, but not fully.
> Basically, if the input consistently uses relative references, the
> result will be predictable. This could certainly be improved more
> though (see the source [1] for details).)
> 
> 
> = Some Details =
> 
> Grit is a different format. This makes it clear that any XSLT (or
> other code) which uses the output isn't intended to transform RDF/XML.
> AFAIK, there is no way -- apart from inventing some hint -- to
> determine if an RDF/XML is "cleaned up".
> 
> I've strived to make transforming Grit as easy as (reasonably)
> possible. This was part of the reason for it  -- I needed a way to
> make a normalized "linked tree" from a graph, and it seemed just as
> well to take it beyond RDF/XML entirely. (As mentioned, even if it
> never becomes an established serialization, it could always at least
> be GRDDL:ed "back".)
> 
> Even if "normalizing" (for some definition of "normalized") RDF/XML
> makes it somewhat easier to transform, I opted to make some
> expressions more compact or easier to handle. Since XPath uses the
> namespace context, using elements for *all* types of a resource
> (within an <a> element) makes it simpler to gather all things of a
> certain type (by matching on the qname). Grit is definitely all for
> namespaces for properties and types (in comparison to e.g. TRiX, RXR,
> etc.).
> 
> Grit does a similar thing for datatypes -- that is it wraps the value
> in an element corresponding to the datatype. I'm not entirely set on
> the current @fmt mechanism, marking literals with a datatype "or" xml.
> I just felt it made sense to "tag" such literals with an attribute,
> meaning the contents should be processed as a value (in part since
> @xml:lang is used for language literals). An alternative would be to
> use e.g. <dt> and <xml> element wrappers, but I'm staying with @fmt
> until otherwise convinced. ;)
> 
> .. I did, at one time, consider gratuitously just "overloading"
> RDF/XML with e.g.:
> 
>    <rdf:type rdf:parseType="Reference"><ex:Thing/></rdf:type>
>    <ex:value rdf:parseType="Data"><xsd:string>datatyped
> 1</xsd:string></ex:value>
> 
> , but I felt that that would be, well, gratuitous.. (and gritty in a
> rather bad way..)
> 
> Lists in Grit use null-namespaced <li> elements, corresponding to the
> content of regular <resource> elements (either carrying @ref
> attributes or representing nested bnodes). Again, my gut feeling is
> that this is intuitive enough. (This, of course, is the
> @parseType="Collection" alternative.)
> 
> Grit *disallows* using bnodes as *objects* of multiple statements
> (mainly because I find bnodes used in this manner quite annoying..).
> All properties of object ("singly linked") bnodes are just put as
> elements within the element corresponding to the property of that
> statement (in the @parseType="Resource"-style). Non-linked bnodes are
> put as top-level <resource> elements sans @uri.
> 
> (Well, the current XSLT actually *copies* the descriptions of bnodes
> used more than once. :P This is something I need to hammer out
> edge-cases for. Regarding a bnode used a multiple objects, I'm not so
> sure, but of course I'll rework them somehow if real need would arise
> (e.g. actually adding e.g. @id and @idref..).)
> 
> 
> = Graphs, Atom =
> 
> Grit can certainly be extended to allow for @uri in the root <graph>
> element, or even allow nested <graph> elements (which of course would
> make transforming it a bit more involved). Naturally, <resource> could
> also be allowed as a root element as well (just as Atom entry
> documents work).
> 
> I do think the format is a bit reminiscent of Atom, albeit there are
> important differences (some mentioned at [2]).
> 
> (If I may aim high, I'd even say that if such graph elements would
> carry, say, <created> and <updated> .., we'd have timestamped named
> graph support. Which incidentally is what I think that Atom entries
> may "actually" represent.. *Describing* those graphs in detail could
> be done with either <resource> elements within them
> ("self::resource/@uri = parent::graph/@uri"), or as property elements
> directly in the <graph>.. I haven't iterated on these ideas much yet
> though. Of course, striving to replace Atom *as well* as a data format
> may be just a bit too bold; but, well, that's what grit is for.. ;D)
> 
> 
> = Further =
> 
> Grit is very much a young work in progress. I'd be happy to
> collaborate on it if others see the same potential as I do.
> 
> It is really a very simple thing, and certainly should pay homage to
> the other existing alternatives. The point is that stepping this short
> step away from RDF/XML, to some extent closer to what Atom *is used
> for*, makes it IMHO look like that "missing format", being true (to)
> RDF while at the same time quite usable as a dead simple "Linked Data
> XML", for those caring less for the merits of RDF.. (But still
> accepting the XML tax*, of course.)
> 
> With all this said, even if no one else finds these higher goals
> promising in this form, I hope Grit is still very usable as an
> instrument for XSLT:ing RDF.
> 
> Best regards,
> Niklas
> 
> [1]: http://purl.org/oort/impl/xslt/grit/rdfxml-grit.xslt
> [2]: http://code.google.com/p/oort/wiki/Grit?ts=1263844538&updated=Grit#Atom
> 
> * = For JSON users, see [3] and my take at [4] instead:
> 
> [3]: http://code.google.com/p/linked-data-api/
> [4]: http://code.google.com/p/oort/wiki/Gluon
> 
> 
> 2010/1/18 Reto Bachmann-Gmuer <reto.bachmann@trialox.org>:
>> I'm wondering what the advantages of grit are when compared with
>> simple subsets of RDF/XML than can be used for XSLT transformation,
>> e.g. Morten's R3X [1].
>> 
>> Cheers,
>> reto
>> 
>> 1. http://www.wasab.dk/morten/blog/archives/2004/05/30/transforming-rdfxml-with-xslt
>> (just to allow XSLT the special RSS 1.0 handling can be ignored)
>