- From: Frank Dengler <frank.dengler@kit.edu>
- Date: Wed, 20 Jan 2010 11:29:18 +0100
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: Semantic Web <semantic-web@w3.org>, Linked Data community <public-lod@w3.org>
- Message-Id: <9C818813-7E76-422C-AA7F-C56A293D6A41@kit.edu>
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) >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 21 January 2010 13:47:03 UTC