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
