I'm not sure the 80% demographic for linked data is getting enough attention. So how about this -
We have : a) timbl's definition of linked data [1] and it seems reasonable to assume that : b) most developers using APIs aren't that familiar with RDF c) JSON is popular with these developers But (playing Devil's Advocate) the work around JSON-LD doesn't consider a), and the work around linked data APIs doesn't consider b). JSON-LD is another RDF format and the framing algorithms intended to transform that format into something JSON-developer-friendly. But I can't see any reference to the linked data principle: "When someone looks up a URI, provide useful information". Without that principle, this isn't really linked data. On the other hand the linked data API has this covered, e.g. in the deployment example [2]: /doc/school/12345 should respond with a document that includes information about /id/school/12345 (a concise bounded description of that resource) Except that to work with a CBD, reasonable knowledge is needed of RDF *and* there isn't really a friendly mapping from arbitrary graphs to JSON. But surely most of the immediately useful information (and ways to find further information) about the resource </doc/school/12345> will be contained in the triples matching: </doc/school/12345> ?pA ?o . ?s ?pB </doc/school/12345> . where ?o and ?s *are not bnodes* (some kind of arbitrary, 'disposable' local skolemisation might be nice, so there was a dereferenceable URI to follow the path, but keeping it simple - just drop bnodes) If we've just looked up </doc/school/12345> we already know that resource. Which leaves two arrays of pairs - a lot simpler than arbitrary RDF graphs. A small snag is ?s, ?p1 and ?p2 will always be URIs, but ?o could be a URI or literal. Also the developer still has to deal with URIs as names, not entirely intuitive. There are probably dozens ways this data could be represented in JSON, but for the sake of example I'll pick one (might be errorful - I'm not that familiar with js) : var forward = [ pA1 : { o1 : "literal"}, pA2 : { o2 : "uri"} ...] var backward = [ s1 : pB1, s2 : pB2 ...] Ok, URIs as names - borrowing an idea from JSON-LD, if we also have some thing like: { "context": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": "http://xmlns.com/foaf/0.1/homepage" ... The data could be presented as e.g. forward = [ "name" : "Fred", "homepage" : "http://example.org" ... allowing easy access via : forward.name[0] and lookup of the URIs if needed : context.name Ideally the resource description would contain both easy-to-use/minimal and anyRDF/maximal data. But maybe a link to a SPARQL endpoint in the easy-to-use/minimal version could provide the latter. Ok, I've glossed over the question of how the consumer app is to know how to interpret the data - but that's a problem for any arbitrary format, like application/xml. [1] http://www.w3.org/DesignIssues/LinkedData.html [2] http://code.google.com/p/linked-data-api/wiki/API_Deployment_Example -- http://dannyayers.com