W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2012

Re: Agenda: JSON-LD Telecon - Tuesday, October 2nd 2012

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 01 Oct 2012 11:36:25 -0400
Message-ID: <5069B879.8000900@digitalbazaar.com>
To: 'RDF WG' <public-rdf-wg@w3.org>
CC: 'Linked JSON' <public-linked-json@w3.org>
On 10/01/2012 10:18 AM, Markus Lanthaler wrote:
> I saw you reassigned the "objectify" issue [1] to the JSON-LD.next 
> milestone. This worries me a bit as we also moved framing there. I 
> wouldn't like to see a JSON-LD API that *requires* another API on top
> of it to be usable in practice.

A few high-level thoughts:

1. This feature is not necessary in order for /JSON-LD/ to be
   usable in practice. We expect most developers and systems to not
   have to modify the incoming/outgoing document at all (as it adds
   more complexity, unnecessarily in most cases). The /JSON-LD API/
   is useful with just .compact(), .expand(), .toRDF(), and .fromRDF().
   It would be nice to have this feature, but the API is useful without
   it.
2. We don't have a proposed solution for .graphify()/.link()
   /.objectify() and we're running out of time to add it to the spec,
   get test cases in shape, and get implementations before REC.
3. This 'layering' approach is a best practice when it comes to
   writing Web-based browser APIs. It lets you get something out of the
   door while keeping the door open for extensions to be added on in
   the future.
4. At some point, we have to draw a 1.0 line in the sand and put
   features that are probably not going to make it on the other side
   of that line so that we can focus on the features that have
   proposals, spec text, and are already in the spec.

> The problem is that the same information can be expressed in various
>  ways and apart from flattening it and then looping over it there's
> no way to access it directly. I think that was one of the problems 
> RDF/XML faced and I wouldn't like to see JSON-LD going down the same
>  path - especially considering that we do have an API.

I agree. If somebody would like to volunteer to write spec text, write
an implementation and write tests... we could more easily move on this.
Nobody has done this work at this point and nobody (with enough time to
move quickly on it) was volunteering to do it.

I'll also note that .objectify()/.graphify() won't solve the .frame()
problem... just because you have an in-memory model doesn't mean that
it's easy to access the data on that in-memory model.

> I would like to discuss this decision briefly, either in the 
> beginning, the end or also in another telecon after we are done with 
> the other issues.

+1 - We'll add it to the beginning of the Agenda.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
http://manu.sporny.org/2012/nuclear-rdf/
Received on Monday, 1 October 2012 15:37:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:51 GMT