W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re: RDFON: a new RDF serialization

From: Bruce D'Arcus <bdarcus@gmail.com>
Date: Thu, 26 Jul 2007 19:02:20 -0400
Message-ID: <46A927FC.8020806@gmail.com>
To: "<>" <_@whats-your.name>, Semantic Web <semantic-web@w3.org>

<> wrote:
>> I'm not so sure I agree with the syntax-is-the-problem tradition. 
>> Surely syntax is one issue, but I tend to think it was just as much
>>  lack of a) well-developed tool infrastructure (since you should be
>>  working with models, not syntax), and b) a standard query
>> language.
> the agile / ruby / python / microformats / web 2.0 developer 
> communities are born from 'languages simple enough that you can write
>  it in notepad' (well, they use textmate). this precludes requiring
> an IDE just to edit stuff, or XML libraries to turn unreadable gunk
> into in-memory models.

As someone drawn to the "agile languages" myself (though not much of a
programmer), I certainly respect the general principle, but not really
the last point. If I have a good RDF library in my language of choice, I
don't care a whole lot about the syntax.

>> Both of those are being resolved.
> can you explain why one query language is a good thing. especially 
> when it introduces another (!) syntax to the equation, and is heavily
>  dependent on argument order for performance. surely exposing basic 
> pattern matching primitives via a REST interface, and letting the 
> user specify queries in XML or JSON does a better job of letting a 
> semantic web organically grow while reusing existing parts, than 
> 'prescribing' a new solution that also requires a new tool chain for 
> parsing/serializing/editing...

My understanding is the decision with SPARQL was to make it a) SQL-like,
and b) similar to N3 (as Tim just noted). And it has XML and JSON 
results formats.

Seems reasonable enough to me.


>> Um ... sure, but what's wrong with N3 or turtle that requires yet 
>> another slightly different syntax? Isn't there a JS-based RDF 
>> parser that can handle N3?
> there are a few. but none are as fast as JSON, since that uses a fast
>  VM level eval(), instead of JS level string parsing regex stuff..
> so JSON gets you the readablity of Turtle without the speed hit of 
> even N3..

OK, so it's better to create a new syntax than to optimize the existing 
infrastructure of N3 tools?

Received on Thursday, 26 July 2007 23:01:58 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:01 UTC