Re: JSON-LD/RDF feedback

A couple more things regarding LD and RDF:

On Thu, Jun 13, 2013 at 10:16 AM, Gregg Reynolds <dev@mobileink.com> wrote:


>
> The third of the four "properties" listed in the intro (which draws on TBL's note) is "the name IRIs, when dereferenced, provide more information about the thing".

This doesn't really work, just because it adds "about the thing".
TBL's original text reads:

"When someone looks up a URI, provide useful information,..."

Adding "about the thing" [i.e. named by the URI] botches it.  Consider
"http://.../Napoleon.html".  I would expect that URI, when
dereferenced, to provided information about Napoleon, not about the
HTML page itself.  In other words, that URI denotes an HTML page;
dereferencing it according to the JSON-LD introduction (quoted above)
ought therefore to provide information about that HTML page, not about
Napoleon.  That obviously doesn't work, since it would mean that the
things named by IRIs should only be about themselves.

But TBL's original text also - "provide useful information" - is not
very enlightening.  "Always wear clean underwear" is useful
information but it would be strange indeed if all URI lookups yielded
that advice.  And besides, what else does anybody expect - non-useful
information?

What I think TBL's item 3 really means is just: when somebody looks up
your URI, do not ignore the request and try not to return a 404 or
other error code.  Which is coming pretty close to vacuous, for my
money.

The original Item 4 isn't much better:  "Include links to other
URIs..".  What's a "link to another URI"?  The intro of JSON-LD is a
slight improvement:  "4) the data expresses links to data on other Web
sites."  But what's that supposed to mean?  Any other website?  The
W3C site?  Can we change this to "my website"?  What do "web sites"
have to do with it anyway - I thought this was about data.

Here's my take on LD:

1.  use IRIs as names of stuff (rather than as URLs, i.e. addresses,
i.e. names of locations);
2.  exploit DNS by using HTTP URIs so that they will be (potentially)
resolvable; in effect this allows your IRI names to be treated as URLs
for the purpose of dereferencing;
3.  configure your servers so that requests for the URIs under your
control are not ignored and do not return errors;
4.  finally, the response you make to requests should include HTTP
URIs as appropriate leading to additional relevant and useful data.

Now that's a pretty clear description of a set of practices.  It still
fudges critical things like what counts as relevant and useful data,
but that's ok, it's a minimal defnition.  Whether this is called
"Linked Data" or not is irrelevant.  So just to avoid pointless
debates about the One True Meaning of LD lets call this "HTTP-Data
Publication Practices" (HDPP).  The essential criteria of demarcation
are just use of HTTP URIs and returning useful and relevant
information possibly including further links.

Note that the Plain Old Hypertext Web - let's call it the web of HTML
data - fits this description, since HTML webpages are data.  So the
four practices are not sufficient to demarcate HTTP-Data (i.e. LD)
from HTML-Data.

Now the question is: how is this related to RDF and JSON-LD?

The most obvious difference is that HDPP as stated does not depend on
the use of formal, explicitly expressed claims (statements) of any
kind, let alone RDF triples.  The same is true of TBL's LD practices
note.

JSON-LD, like RDF, does involve the expression of claims in this
sense, even if it does not say so explicitly: it's built-in.  But its
definition of LD in the intro muddies things since it includes an
unworkable stipulation that what a URI names should be about the URI.
Furthermore, insofar as JSON-LD claims to be a kind of LD language,
while sticking to a definition of LD that does not include explicit
claims, and at the same time deploys an explicit claim language while
more-or-less pretending it doesn't (i.e. disingenuously), it is
inconsistent.

The conclusion I draw is that JSON-LD obviously does deploy explicit
claims (in the form of covert triples).  But it does not follow that
we are compelled to say that it deploys (or uses, is based on, etc.)
RDF.  In other words, I don't see a warrant for the implicit claim
that RDF is synonymous with support for expression of explicit claims.
 So I don't see a problem with not smearing "RDF" all over the spec,
but I do see a relatively big problem with trying to hide the fact
that JSON-LD is for expressing claims explicitly using the same
(conceptual) device RDF uses, and for denying that it is in fact an
extension of plain old LD (or HTTP-Data).  So I will probably think of
it (and explain it) as an LD language extended by explicit claims
using a (covert) topic-comment regime, which allows it to directly
express RDF graphs.

Cheers,

Gregg

Received on Friday, 14 June 2013 07:30:56 UTC