Re: Fwd: RDF/JSON

>> How many production systems have you deployed using JSON-LD vs. RDF/JSON?

None, as I said in my original email

>> Why not just TURTLE or N-Triples? What are the benefits of JSON if you
have RDF-aware clients/servers?

Because programming libraries for handling TURTLE or N-Triples are not
universally available, are of dubious quality when they exist, and are not
standardized - they each come with some sort of proprietary API for
exposing the result data. By contrast, almost every language has standard
support for JSON, and the result of deserializing RDF/JSON is the
"universal API" that everyone already knows and for which almost all
languages have excellent support - dictionaries and arrays.

>> Why? What makes it the 'natural way'? Why is RDF/JSON the 'format for
programmers'?

See previous comment.

>> We expect that most useful
>> JSON-LD will end up looking like this:
>> {
>>  "@context": "http://example.com/context.jsonld",
>>  "key1": "value1",
>>  "key2": "value2"
>>}

I think that most web programmers would view the '@context' stuff as just
annoying extra stuff they don't need or use. And if the RDF has multiple
subjects - which is the case with a lot of our data - the level of
annoyance will be much higher than shown in this example. This is why I
believe that if you really need to appeal to a web crowd, you will need two
different formats, one for the web crowd, and another for the RDF-aware
crowd. I would only use JSON-LD if it was impossible for me to support two
formats. While the JSON-LD format is much less annoying to web developers
than the RDF/JSON - at least for simple cases - it's also more annoying
than their current version, and I do not see how those people are getting
any value in return for the annoyance. Better to put that information in a
separate media type that is for the RDF-aware people. For RDF-aware people,
JSON-LD is also annoying - it is much more difficult to parse than simple
RDF/JSON. If every programming language had a JSON-LD library that had no
bugs, loaded in zero time, took zero space and had an API everyone loved,
this might not be an issue, but those things are not true.

I would note also that for your approach to have appeal, it is not enough
for you to say "My API is JSON-LD", you have to say "My API produces only
the compact form of JSON-LD", since if your API ever produced any of the
other forms, your "web clients" would certainly fall over dead. You will
also have to say something about what you accept on input. Do I have to
give you a correct context on input, for example when I GET something,
update it and PUT it back? If I do, web programmers may find this quite
onerous. If I don't have to give you a context on input, what can you say
about the API? Is it "JSON-LD compact form on output, but custom JSON on
input?"

>> The document above is far more useful to a regular Web developer than
>> its RDF/JSON counterpart:
>> {
>>  "_:bnode1": {
>>    "http://example.com/vocab#key1": {
<http://example.com/vocab#key1>
>>      "value": "value1"
>>      "type": "literal"
>>    },
>>    "http://example.com/vocab#key2": {
>>      "value": "value2"
>>      "type": "literal"
>>    }
>>  }
>> }

I actually doubt that is the correct translation of the intent of the "web
JSON". I think it more likely to be:
{
  "": {
    "http://example.com/vocab#key1": {
<http://example.com/vocab#key1>
      "value": "value1"
      "type": "literal"
    },
    "http://example.com/vocab#key2": {
      "value": "value2"
      "type": "literal"
    }
  }
}

In other words the subject is the null relative address with the base being
implied by the URL you used to retrieve the resource (or maybe the
Content-Location response header). However, I agree with your real point,
which is that web developers are not going to like the RDF/JSON format.
It's not for them, and in my recommended approach they never see it.

>> I hope you do as the opinion you have expressed is very much in the
minority based on the feedback we've received from developers

Well, being in the minority is often a good sign - when too many people
agree with me I start to worry. I would nevertheless be interested in
learning more about the other feedback you have received.

>> You may want to watch this to get an idea of why Web developers prefer
simple key-value data structures

Nice video - are you the narrator? You did a nice job. I didn't see
anything there that changed my mind, though. I think JSON-LD makes some
sense if you start from the premise that you need one representation that
will satisfy both RDF-aware and RDF-unaware clients. I don't think that
premise is right - I think it leads to something that neither group will
really like, and neither group gets any benefit from the compromises that
are introduced to try to accommodate the other. I'm not interested in
trying to stop those who like JSON-LD from having what they want - I'd just
like there to be something out there for people like me who aren't
interested. Fortunately RDF/JSON fits the bill quite well. It would be
preferable if the W3C did not try to present JSON-LD as a replacement for
RDF/JSON - it isn't - and I promise I will not claim that RDF/JSON is a
replacement for JSON-LD. Regardless of what the W3C says, my team is likely
to continue using RDF/JSON.

In the interests of full disclosure, our current software only has one API
- the RDF/JSON one - probably because all the clients we have so far are
ones we wrote ourselves that are RDF-aware. If and when we are in
production and if and when we get a lot of push-back on our APIs, I guess
we'll have to look at providing an alternative for the non-RDF crowd. Since
we haven't written this, I can't say exactly what it would look like.

Regards, Martin


On Tue, Apr 30, 2013 at 5:23 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> On 04/30/2013 01:37 PM, Martin Nally wrote:
> > Based on our experience implementing applications, this is the
> > advice I am giving people at IBM, and anyone else who asks me.
>
> How many production systems have you deployed using JSON-LD vs. RDF/JSON?
>
> > 1) If you are writing RDF-aware clients and servers, and you are
> > looking for a data format for the interface between them, use
> > RDF/JSON.
>
> Why not just TURTLE or N-Triples? What are the benefits of JSON if you
> have RDF-aware clients/servers?
>
> > This is true whether or not you were previously interested in JSON.
> > Think of RDF/JSON as the natural way for RDF-aware programs to talk
> > to each other, regardless of other technology choices - it's the RDF
> > format for programmers.
>
> Why? What makes it the 'natural way'? Why is RDF/JSON the 'format for
> programmers'?
>
> > 2) If you have an existing JSON format, and you want to extend it so
> > it is more self-describing for RDF-aware clients, consider using
> > JSON-LD. An alternative is to offer two different media types - your
> > current one and RDF/JSON
>
> Our experience has shown us that most Web developers don't care about
> RDF. They care about data structures that are easy to work with,
> specifically, JSON is really nice. RDF/JSON is a bit of a nightmare to
> work with for a large subset of Web developers.
>
> > 3) If you are designing a new RDF-aware server and you want to
> > expose it to both RDF-aware and RDF-unaware clients, offer two
> > different media types - RDF/JSON plus "web JSON". Offering JSON-LD
> > will not be popular with either the web crowd or the RDF crowd, both
> > of whom will view it as unnecessarily complex from their point of
> > view.
>
> JSON-LD is more concerned about the "Web crowd" than the "RDF crowd".
> The "RDF crowd" has never had a problem with consuming and publishing
> RDF. However, the RDF crowd has stayed very small over the past decade
> due to the lack of a good data format that is useful to the broader
> programming community.
>
> JSON-LD's approach is to embrace what's currently working on the Web
> (JSON), and augment it such that it's not changed into something that
> Web developers won't recognize (RDF/JSON). We expect that most useful
> JSON-LD will end up looking like this:
>
> {
>   "@context": "http://example.com/context.jsonld",
>   "key1": "value1",
>   "key2": "value2"
> }
>
> The document above is far more useful to a regular Web developer than
> its RDF/JSON counterpart:
>
> {
>   "_:bnode1": {
>     "http://example.com/vocab#key1": {
>       "value": "value1"
>       "type": "literal"
>     },
>     "http://example.com/vocab#key2": {
>       "value": "value2"
>       "type": "literal"
>     }
>   }
> }
>
> > It is possible I will change my mind as I learn more
>
> I hope you do as the opinion you have expressed is very much in the
> minority based on the feedback we've received from developers. I think
> you might be conflating a good dump format (like N-Triples and RDF/JSON)
> with something that developers would like to use (like JSON / JSON-LD).
> You may want to watch this to get an idea of why Web developers prefer
> simple key-value data structures vs. the SPO data structures of RDF:
>
> http://www.youtube.com/watch?v=vioCbTo3C-4
>
> RDF/JSON is disconnected from what Web developers expect from a modern
> Linked Data serialization format.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
>