Re: Minimum useful linked data

Hi Danny,

You wrote...

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

Here [1] is a way of extending semantics to the consumer app:

*Abstract*:

*There has been much progress assigning semantics to data. However the
meaning that resides in an application (or in a SPARQL query) should be
taken into account. Even if data identifiers and ontologies have really fine
readable meanings, an application can change the semantics completely. And,
unless there are explanations of what the app has done, no-one will be any
the wiser unless the error is egregious (eg -- the Eiffel tower is a dog). *

*This talk [1] describes a system [2] on the Web that combines three kinds
of semantics -- (a) data -- as in SQL or RDF, (b) inference -- via a theory
of declarative knowledge, and (c) open vocabulary English. The combination
is used to answer questions over networked databases, and to explain the
results in hypertexted English. The subject knowledge needed to do this can
be acquired in social network style, by typing executable English into
browsers. *
Thanks for comments.              -- Adrian

[1]
http://www.w3.org/wiki/HCLSIG/SWANSIOC/Actions/RhetoricalStructure/meetings/20110711

[2]  A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over
SQL and RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering




On Sat, Sep 3, 2011 at 1:34 PM, Danny Ayers <danny.ayers@gmail.com> wrote:

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