Re: JSON-LD/RDF feedback (Linked Data & RDF Conflation Deconstructed)

FYI:

I am cc'ing this list because the it provides a very good analysis of 
the current problem re. Linked Data and RDF conflation.

I encourage you to read on....

On 6/14/13 3:30 AM, Gregg Reynolds wrote:
> 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
>
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen