W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Simpler alternative of Linked Data semantics (was Re: Is 303 really necessary?)

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 28 Nov 2010 18:48:11 -0500
Message-ID: <4CF2EA3B.1040006@openlinksw.com>
To: Jiří Procházka <ojirio@gmail.com>
CC: Linked Data community <public-lod@w3.org>
On 11/28/10 3:52 PM, Jiří Procházka wrote:
> On 11/28/2010 06:45 PM, Kingsley Idehen wrote:
>> On 11/28/10 9:46 AM, Jiří Procházka wrote:
> <snip>
>>> This problem is caused that Linked Data conflates identifiers with
>>> locators - important is that one can get information about a unique
>>> name, by using it as a locator.
>> Linked Data (meme or actual concept) doesn't conflate Locators with
>> Identifiers. A URI is a generic Identifier. A URL (a Locator / Address)
>> is an Identifier.
>> The problem remains in not understanding the URI abstraction.
>> One issue you can't tack on Linked Data is failure to distinguish
>> between a Name Reference and an Address Reference implemented via
>> elegance of URI abstraction.
>>>    The issue whether some events in the
>>> process or outcome of the information retrieval somehow should affect
>>> users perception of the name (is it a document or xyz?) is a can of
>>> worms most implementers don't want to tackle and they have a point.
>> It wasn't a can of worms before the Web. The issue of "Resource" in URI
>> [1] has lead to overloading that creates the illusion you describe,
>> across many quarters and their associated commentators.
>>>    I
>>> don't want to maintain all apps I once coded so they support whatever is
>>> the latest HTTP semantics trend is, when there is a widely used standard
>>> for extensible, *evolvable* information representation (RDF) which I am
>>> already expecting to receive about the name I am retrieving info about.
>>> So lets not presume that by dereferencing an URI and getting back a
>>> document, the URI is the documents identifier - it is its locator.
>> Yes, it's the URL of a Document, and if the content-type is one of the
>> RDF formats, or any other syntax for representing EAV model structured
>> data -- via hypermedia -- then its the URL of a Entity Descriptor
>> Document -- a document that provides a full representation of its
>> Subject via a Description expressed in a Graph Pictorial comprised of
>> Attribute=Value pairs coalesced around Subject Name (an Resolvable
>> Identifier e..g an HTTP URI).
>>> It
>>> can be its identifier too, but lets leave that for publishers to decide
>>> - that has been the point of my previous post on the topic (
>>> http://lists.w3.org/Archives/Public/public-lod/2010Nov/0325.html )
>> If you mean, let the publisher decide via Content and Mime Type what
>> this is about, then emphatic YES!!
> That is the option which was promoted till now, but some people chose
> not to oblige for whatever reason and judging by the amount of
> discussions about it, it is a problem. If publisher makes available
> structured data about some concept at an URI he probably means the URI
> identifies the concept, not the data documents, and I think if one wants
> to use that data, he needs to try to understand the publisher, not tell
> him he is wrong because [insert XX pages of HTTP&  URI semantics],
> however flawed neglecting the standards you may consider to be - welcome
> the Linked Data (tag^H^H^Hstatus-code-)soup.
> I'm fond of RDFs take on URIs == names. What I mean is:
> a)  letting publisher decide which name is for document and relations
> between them, which for concepts. On dereferencing (200 returned), not
> to think "hmm yup, this definitely must be name for a document", but
> "hmm I dereferenced this URI and got back some document" - the document
> exists, but it's name isn't specified - like blank node, with similar
> drawbacks, thus:
> b)  letting the publisher decide that not via Content and Mime Type, but
> in the structured data itself, because that is most probably what the
> consumer will be able to parse and understand anyway and there exists a
> well established standard Resource Description Framework for it which
> fulfills more of this great document (
> http://www.w3.org/DesignIssues/Evolution.html ) than HTTP, which isn't a
> one ring to rule the all transport protocols. (Other data formats than
> RDF should have equivalent ways of expressing that too.)

Yes-ish, but my point is this:

1. Publisher (owner of Linked Data Server) serves up data via Documents 
at URLs
2. Linked Data Client (agents) accesses data by exploiting content 
negotiation when de-referencing URIs (Name or Address)
3. Publisher sends Document Content to client with metadata (HTTP 
response headers and/or within the content via triples or <head/><link/> 
exploitation re. HTML) -- this is where Mime Type comes into play too
4. Linked Data Client processes metadata and content en route to 
understanding what its received.

> This practice doesn't need to be standardized. You and me can use it now
> if we wish. It has both advantages, covering wider quality range of
> linked data, and disadvantages - suddenly all documents with no data
> about them have no names! Tragedy? No, we have their locators and if
> there is something said about the locators, we can assume it is about
> the document stored there, unless said otherwise by the publisher (this
> is the difference from the standard Linked Data perspective).
> This doesn't make ambiguity to go away, that is impossible since it
> depends on the publisher, but I believe it is a simpler, more forward
> compatible way to go around it, fitting more world-views.

I don't think we are in disagreement, we just need to understand 
ourselves e.g., what I meant by mime type as piece of metadata used to 
understand content retrieved from a URL by a user agent.

> Best,
> Jiri
> <snip>
>> Links:
>> 1. http://lists.w3.org/Archives/Public/www-tag/2009Aug/0000.html --
>> TimBL's own account re. origins of "Resource" in URI. This is the problem!!



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Sunday, 28 November 2010 23:48:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC