Minimum useful linked data

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

Received on Saturday, 3 September 2011 17:35:42 UTC