Re: [JSON] Modularization and JSON-LD

On 04/06/2011 07:50 AM, Steve Harris wrote:
>> He asked whether or not JSON-LD was designed to be a kitchen-sink 
>> specification - that is, it seems to try to support everything - a
>> full RDF serialization in/on/with JSON.
>> 
>> I attempted to clarify by saying that the only reason it seems like
>> it is trying to support everything is because we wanted to have a
>> number of object-based solutions ready when this working group
>> started. We thought that we could save some time in this WG by
>> doing due diligence on a complete, object-based representation of
>> RDF in/on/with JSON.
> 
> So, I'm still a little confused about what the use-case is for this
> style of RDF serialisation.

I don't think there is a single use case, as it is attempting to achieve
at least two goals:

 * Give JSON developers something that they can use JSON.parse() on and
   use without having to think too hard about the RDF aspects if they
   don't want to think about the RDF aspects.
 * Give RDF developers something that they can provide JSON developers
   that is fairly easy to generate (we have working code that can take
   a graph and construct a good JSON-LD document from that graph -
   whether or not it contains cycles, diamonds, etc.)

There are a few others, but that is optional/kitchen-sink stuff.

> As a company that uses a lot of JSON and RDF, we ought to be square
> in the target audience (shouldn't we?), but I just don't see how it
> helps us.

I don't think that necessarily puts you in the target audience. If you
had thousands of Web Apps developers that used your APIs and they knew
next to nothing about RDF, but also had a few that cared about Linked
Data/RDF - you might be in the target audience. That is, if you were
Twitter, Facebook, FourSquare, Google Maps, Digg, or someone that would
like to launch a popular RDF-backed API - you're in the target audience.

There is no problem if both provider and developer want to use TURTLE,
or RDF/XML, or HTML+RDFa. However, if your developer population doesn't
know anything about RDF, but still wants to use your APIs - there is a
big problem.

> The goal seems to be some kind of duality where "Javascript people"
> can consume it natively as JSON, and "RDF people" can consume it as
> triples, but I'm not clear on how either part wins over what we have
> now. 

There is no single serialization that is both massively popular (JSON)
and Web-scale (RDF). We don't have anything like that right now.

> Wouldn't it be better for everyone if the people publishing data
> offered Turtle as well as JSON for their results? 

No. That's like saying: "Wouldn't it be better if people just provided
RDF/XML beside their HTML content?". We've gone down that road as a
standards community and it was (with much respect to everyone involved
in the earliest forms of RDF) a dismal failure.

> A bit like Twitter
> for e.g. offers XML, RSS, and Atom as well as JSON. I'd rather see
> http://api.twitter.com/1/statuses/public_timeline.ttl, than
> http://api.twitter.com/1/statuses/public_timeline.json being bloated
> with a load of RDF-y annotations.

Not everyone has the type of development resources to provide multiple
data streams. Plus, wouldn't it be better if the world just used one
well-designed, universal data format for Web Services?

Plus, I don't think the "bloat" has to be there. For example, JSON-LD
has the concept where you can assume a pre-specified @context, or you
can load in vocabulary profiles. In the first case, there can be zero
bloat. In the second case, the "bloat" is one line, listing the
vocabulary profile.

> As far as I can tell, it's not possible to make an easy-to-consume
> serialisation from RDF you hold now

Sure it is... it just may not look like what you want it to look like.

> it has to be hand-templated in
> order to make it pleasant to consume in Javascript. That's the same
> problem as RDF/XML, and XML parsers.

Yes, it does have to be hand-templated. Any data structure that allows
nesting and cycles has to be hand-templated for any real-world
application. It is the same problem as RDF/XML and XML parsers, but
that's not a problem that we're interested in solving.

Why should we be interested in solving this problem?

> Forgive the cynicism but it seems like all these proposals give you
> either confusing, and ugly JSON, or inconvenient, and cutdown RDF
> subsets. We don't have a use for either of those.

I think you're over-generalizing.

 * Some of these proposals give you "confusing" JSON. (subjective)
 * Some of these proposals give you "ugly" JSON. (subjective)
 * Some of these proposals give you "inconvenient" JSON. (subjective)
 * Some of these proposals give you cut down RDF subsets. (objective)

However, to say that they don't solve problems for a subset of the
communities that we're discussing is going too far. That is, it may not
solve a problem for you - but that doesn't mean there aren't many other
people out there for whom it does solve a problem.

To approach this from another angle - I don't get why people love Ruby.
I've tried to like it several times over the past decade, but since I
learned Python first - I just can't seem to appreciate the language.
However, that's not to say that it is not very useful for a large group
of people out there.

That said - I don't know if this is a convincing line of argumentation
for you.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The PaySwarm Vocabulary
http://digitalbazaar.com/2011/03/31/payswarm-vocab/

Received on Thursday, 7 April 2011 01:55:34 UTC