- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 01 Oct 2012 11:36:25 -0400
- 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 UTC