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

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

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.

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