Re: Cycles

Well,

I may be wrong, but I have the gut feeling that JSON is different from
XML in that respect. I tend to consider that DOM/Infoset/... are
data-models put to the service of the XML syntax, while JSON is a syntax
put to the service of a very simple and programmer-friendly data-model.

So, in my view, JSON-LD is not so much about providing a syntax for RDF
that is eye-candy for web developers, than it is about providing a
mapping between RDF graphs and simpler data structures, that happen to
look nicer in JSON.

I'm especially very fond of the notion of Compaction [1]: this mechanism
makes a JSON-LD document as compact as possible with the help of a given
context. I see that the algorithm is a work in progress, if this can be
achieved for any JSON-LD document, it means that it can work for any RDF
graph.

So with the compaction algorithm, a JSON-LD context becomes an
application-specific *point-of-view* through which a programmer can
"look at" an RDF graph as a friendly data-structure. Information that is
not taken into account by that context is still available, either by
using full IRIs instead of short names, or by switching to a different
context.

So, I do agree with Dan that

  some more careful investigations into RDF usability might repay the
  investment

but I also think that JSON-LD provides a nice direction for this kind of
investigation.

  pa

[1] http://json-ld.org/spec/latest/#compaction

On 08/26/2011 09:30 AM, Dan Brickley wrote:
> On 25 August 2011 01:23, Ian Davis <ian.davis@talis.com> wrote:
>> Perhaps a little light relief :)
>>
>> I came across this after Danny Ayers linked to one of his
>> contributions to the thread.
>>
>> http://lists.w3.org/Archives/Public/www-rdf-interest/2002Nov/0003.html
>>
>> Best read by squinting so the letters X,M,L look like J,S,O,N
> 
> Well, quite.
> 
> The RDF community has a distressing tendency towards syntax-envy,
> always looking jealously at the greater adoption levels enjoyed by
> other syntaxes. Unfortunately the issue will never be fixed by making
> (some version of) RDF look more like the most currently fashionable
> data syntax. Our problems are deeper: XML and JSON can be prettier
> because that's all there is to them. Unlike RDF, they're not a mapping
> from a concrete syntax to a different, invisible, abstract data-model.
> Sure there are canonical abstractions (Infoset/DOM etc.), but there is
> not the same mis-match between how-it-looks and how-it-works that RDF
> tends to bring to the table.
> 
> The idea of pushing work into syntactic-schema annotations has been
> around almost as long a RDF, but never caught on. Our only
> standards-track effort in that direction, GRDDL, doesn't seem widely
> loved (although
> http://search.cpan.org/~tobyink/JSON-GRDDL-0.001_00/lib/JSON/GRDDL.pm
> remains intriguing).
> 
> While we can always do more work to improve things on the syntax
> front, I feel it's often used as an excuse for deeper, subtler
> problems that face RDF adoption, and that some more careful
> investigations into RDF usability might repay the investment.
> 
> In http://www.slideshare.net/danbri/when-presentation-849447 I touched
> on three mini post-mortems for situations where RDF was used and
> rejected, or where we'd have expected it to be used, and it wasn't. In
> none of those situations was syntactic elegance a major consideration;
> rather, it was working with RDF 'as RDF' and its available tooling
> that caused the problems. RDF tools continue to improve, but even if
> we come up with the most beautiful and elegant XML^H^H^HJSON syntax
> for encoding RDF, there's much more to working with RDF than merely
> parsing it.
> 
> cheers,
> 
> Dan
>

Received on Monday, 29 August 2011 16:49:39 UTC