Re: [JSON] Modularization and JSON-LD

Thanks for replying Manu, the message came off more abrupt than I was intending, I dashed it off between meetings. Comments inline.

On 2011-04-07, at 02:55, Manu Sporny wrote:

> 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.)

OK, but these aren't usecases IMHO, they're more like scenarios. I was thinking more of "Company A wants to publish [such and such], and User X wants to [do something]...".

> 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.

I meant the target audience for consumers. As you guessed, our users don't even want JSON, let alone RDF.

We use the Twitter API (amongst many others) and get JSON from it, and were a big RDF user, but we don't have any desire for RDF from Twitter, it doesn't help us in any way.
 
> 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.

Not really, you just use JSON, and everyone is happy.

>> 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.

That's true, but 1) I'm don't see the need for it, and 2), it's arguably answered better by JSON-triples, or one of the not-natural-in-JSON formats.

The fact that Twitter support so many different serialisation formats for results suggests that having a single format isn't really a big win.

>> 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.

People do provide RDF/XML alongside HTML, it's called RSS usually.

>> 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?

Not necessarily - it depends what compromises are required.

> 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.

Perhaps, but I've not yet seen a compelling example, that covers a significant proportion of RDF features.

>> 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.

So, that would not be easy to consume, I believe.

>> 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.

OK, but that rules out all usescases where the application is internally RDF, and your publishing RDF/JSON from it. That may or may not be significant.

If it has to be templated then it's no easier than publishing Turtle.

> Why should we be interested in solving this problem?

It was on the scenario grid, so I assumed we were interested in it in some way.

>> 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)

True, but I wasn't trying to be objective, I was trying to understand why none of these proposals seems interesting, when I believe we should be square in the intended audience (of consumers).

> * 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.

Sure, so I'd like to see their use cases. It's hard for me to imagine hypothetical use cases for people that would benefit from being able to consume JSON data as RDF (or vice versa) - that doesn't mean they don't exist, but without a handful of believable use cases I can't possibly judge the fitness of a particular solution.

> 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.

Sure, I see the parallel, but I can comprehend why people want Ruby, even though I don't use it myself.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Thursday, 7 April 2011 13:59:16 UTC