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

On 11/29/2010 12:48 AM, Kingsley Idehen wrote:
> 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.

Right, essentially I was pointing out the advantages of publishing the
metadata in the content itself, in contrast to relying on HTTP. My bad
for not realizing the role mime types can play as metadata outside of
transport protocol.

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