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

This discussion is getting out of hand. What conflation are you talking
about?

I really don't get it anymore and it's starting to become annoying.


On Fri, Jun 14, 2013 at 1:23 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote:

>
> 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<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>