Re: RDF Syntaxes 2.0

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