Re: RDF, XML, XSLT: Grit
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) 2010/1/17 Niklas Lindström lindstr...@gmail.com: Hi all! In light of the recent discussions about both using RDF in contexts where RDF awareness and availability of RDF tools are more limited, and in relation to the thoughts on RDF/XML (re-)emerging in the RDF 2.0 discussion thread [1], I find it timely to document and announce an instrumental format I recently made, called Grit (Grokkable RDF Is Transformable), at [2]. I made this primarily for using XSLT to produce (xhtml) documents from controlled sets of RDF, e.g. vocabularies and such. I've found it conventient enough to think that there may be general interest. As described at [2], Grit deviates from RDF/XML to form a syntax with as little variation as possible (partially comparable to normalized, pretty RDF/XML). I would love feedback if you find this to be interesting, either for just XSLT/XQuery etc., or even as (yet another..) RDF format usable in its own right (for instance, I do suspect that something like it would be easier to sell in Linked Data contexts than either RDF/XML or e.g. TriX). (In the works I also have an XSLT-based chain for producing XHTML documentation from RDFS/OWL vocabularies transformed to Grit (basically a pedagogical cleanup of existing code I use in my work), and a GRDDL XSLT to take Grit back to RDF/XML, for good measure.) Best regards, Niklas Lindström [1]: http://lists.w3.org/Archives/Public/semantic-web/2010Jan/0068.html [2]: http://code.google.com/p/oort/wiki/Grit
Context Tags, Context Sets and Beyond Named Graphs...
For a while I've been struggling with a number of practical problems working in RDF. Some of these addressed by Named Graphs as they currently exists, but others aren't. Over the weekend I had an idea for something that I think is highly expressive but also can be implemented efficiently. The idea is that the context of triple can be, not a name, but a collection of tags that work like tags on delicious, flickr, etc. Tags are going to be namespaced like RDF properties, of course, but they could have meanings like: #ImportedFromDBpedia3.3 #StoredInPhysicalPartition7 #ConfidentialSecurityLevel #NotTrue #InTheStarTrekUniverse #UsedInProjectX #UsedInProjectY #VerifiedToBeTrue #HypothesisToBeTested Individually I call these Context Tags, and the set of them that is associated with a triple is a Context Set. Now, named graphs can be composed from boolean combination of tags, such as AND(#ImportedFromDbPedia3.3,#InTheStarTrekUniverse) NOT(#NotTrue) AND(NOT(#ConfidentialSecurityLevel),OR(#UsedInProjectX,#UsedInProjectY)) === Note that this is a feature of the underlying storage layer that can be exploited by layers of the RDF store that are above: for instance, something just above the storage layer could hash the subject URL and then pass a physical partition tag to that the actual storage layer. Similarly, security rules could be applied automatically. === There are many details to be filled in and features that could be added. For instance, I could image that it might be useful to allow multiple context sets to be attached to a triple, for instance, if you had the triple :WarpDrive :isA :SpacePropulsionDevice it might be desirable to assert this as #RealWorld #NotTrue and to also assert that it is #InTheStarTrekUniverse I've thought through the implications of this less, however. The immediate use for this system that I see is that existing query mechanisms for named graphs can be applied to the computed graphs. Inference mechanisms that can do other things with context tags is a wide open question. === Anyhow, I want this pretty bad. (i) If you're selling this, I'm buying; (ii) if you want to build this, contact me.
Re: Context Tags, Context Sets and Beyond Named Graphs...
Hi Jeni, 2010/1/18 Jeni Tennison j...@jenitennison.com: Do you think that http://www.w3.org/2004/03/trix/rdfg-1/ is sufficient for describing the relationships between graphs (for these purposes) and if not, what do you think needs adding? No I don't think its sufficient, certainly not for the kinds of use cases that Paul was describing. The RDFG schema only has two properties defining equivalency and a sub-set relationship. I was thinking more along the lines of a means to describe the process of constructing a graph by operations on a set of other graphs, where those operations would include basic algrebra operators. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com
Re: RDF, XML, XSLT: Grit
Hi Niklas, 2010-01-17 18:53 Niklas Lindström lindstr...@gmail.com: I made this primarily for using XSLT to produce (xhtml) documents from controlled sets of RDF, e.g. vocabularies and such. I've found it conventient enough to think that there may be general interest. My feedback will be … I would love feedback if you find this to be interesting, either for just XSLT/XQuery etc., or even as (yet another..) RDF format … … of that kind: I have successfully done some XSLT processing with RXR (http://wiki.oasis-open.org/office/RXR, http://www.dajobe.org/papers/xmleurope2004/). I found it very nice for XSLT processing, as there is exactly one way for writing down things. On the other hand, it's a bit harder to read for humans, as it always uses full URIs, and there is not syntax for anonymous bnodes; you always have to give bnodes an ID. Still, whatever syntax it will be in the end, I support any initiative towards deprecating RDF/XML or at least introducing a machine-friendly XML syntax in RDF 2.0. Cheers, Christoph -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
Re: Context Tags, Context Sets and Beyond Named Graphs...
This description reminds me of NRL, maybe it is closer to what you need. http://www.semanticdesktop.org/ontologies/nrl/ Axel On Jan 18, 2010, at 21:47 , Leigh Dodds wrote: Hi Jeni, 2010/1/18 Jeni Tennison j...@jenitennison.com: Do you think that http://www.w3.org/2004/03/trix/rdfg-1/ is sufficient for describing the relationships between graphs (for these purposes) and if not, what do you think needs adding? No I don't think its sufficient, certainly not for the kinds of use cases that Paul was describing. The RDFG schema only has two properties defining equivalency and a sub-set relationship. I was thinking more along the lines of a means to describe the process of constructing a graph by operations on a set of other graphs, where those operations would include basic algrebra operators. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.do...@talis.com http://www.talis.com -- axel.rauschma...@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Re: RDF, XML, XSLT: Grit
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=Referenceex:Thing//rdf:type ex:value rdf:parseType=Dataxsd:stringdatatyped 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
