- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 28 Nov 2010 18:48:11 -0500
- 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!! >> -- Regards, 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