- From: Dave Beckett <dave@dajobe.org>
- Date: Mon, 25 Jan 2010 08:33:17 -0800
- To: Richard Light <richard@light.demon.co.uk>
- CC: semantic-web@w3.org
Richard Light wrote: > In message <4B5D2E3D.3000700@dajobe.org>, Dave Beckett <dave@dajobe.org> > writes > >> People moan about RDF/XML and have for years. I even wrote down in great >> detail the flaws in [1]. Over all that time nobody has come up with a >> credible and complete XML syntax alternative that stuck, even myself. >> Let >> me summarize the ones I know: >> - TriX: had little takeup >> - RXR[1]: ditto >> - GRIT: new, but flawed since it can only represent trees (no named >> bnodes) > > Your comments focus on the "writing down" aspect of various RDF > serializations, and human perceptions of e.g. XML. That's one part of > the story, but effective machine processing is another, and one which is > pretty central to the whole Linked Data initiative. > > I would like to see agreement on an RDF serialization which allows > lossless transfer of machine-processible Linked Data between agents. For > this purpose, RXR or something very like it would seem to me to be > perfectly adequate. Actually N-Triples has proven probably the most effective at that since it a) was simple (only one way to do anything) b) was complete (and basically RXR was copying N-Triples, but in XML) [we can argue that the spec could be improved, but that's the case for almost all the specs] I don't think there have ever been more than trivial interop problems with N-Triples. Maybe it is because people could understand it in a few minutes. When this is presented on slides, it barely needs more than 1, which makes understanding interop good. RDF/XML and maybe RXR too, not so much. >> So I'm happy with how Turtle turned out and that should be the focus >> of RDF >> syntax formats *for users*. It does need an update and I'll probably >> work >> on that whether or not a new syntax is part of some future working >> group - I >> have a pile of fixes to go in. Adding named graphs (TRIG) might be >> the next >> step for this if it was a standard. >> >> It may be there is a need for a better machine format, but please >> don't mix >> them. Also, machines can read Turtle RDF :) > > They can: I have had a bash at writing a Turtle parser myself. However, > I found issues with the spec itself, and with the way my target data and > Protege have interpreted it [1, last para]. Well, that we (I) can fix. I wasn't very happy with the way the spec syntax : triples mapping was written, but I hoped the test cases made things clear where words didn't. > The advantage of using an XML application to serialize RDF is that > developers can then turn to a base layer of XML-capable software on > which to build any application-specific capabilities or optimizations > that are required. If you want to consume Turtle in your Linked Data > tool chain then you have to start from a lower base, code-wise. That was the theory way back and reusing the XML stack: - XML Namespaces - XML Base - XML Infoset (RDF/XML Revised) provided by an XML DOM / SAX / XmlReader / ... API but it turns out still pretty easier to just do - Turtle lexer + parser (and you have to have a good URI implementation for both cases) > For working with RDF graphs, wouldn't it be useful to define a "DOM/API > for RDF"? This would be a programmatic API exposing the structure of a > parsed RDF graph, and offering a range of operations on it. (Or have I > just missed the fact that this already exists? - entirely possible.) > > Best wishes, > > Richard > > [1] http://lists.w3.org/Archives/Public/semantic-web/2010Jan/0236.html That's come up before but the DOM for HTML/XML has had it's own interop problems, at least in browsers. There might be a lesson from that. I think primarily the Java world would benefit from this since there would be several major systems that could use it and it's a world that likes Enterprise Standard APIs That Start With J (TM) Dave
Received on Monday, 25 January 2010 16:33:50 UTC