On 6/13/11 9:59 AM, Christopher Gutteridge wrote:
The real problem seems to me that making resolvable, HTTP URIs for
real world things was a clever but dirty hack and does not make any
semantic
sense.
I think its an ingenious tweak, but easily perceived as a "clever but
dirty hack".
As you know, the problem with HTTP URI based Names is that they are
unintuitive. Thus, the entire narrative re. Linked Data should never
have built solely around use of HTTP scheme based URIs for Names. It
could have just started with URIs and worked its way toward the benefits
inherent in using HTTP scheme URIs due to encapsulation of de-reference
(indirection) and address-of operations. Instead, as I've stated
repeatedly, we oscillate between use of URI and URL for a concept that
leverages all aspects of the URI abstraction.
HTTP URI based Names ultimately deliver the least disruptive path of a
global data spaces of data objects represented by linked data graphs. We
just need to fix the narrative, and that starts by decoupling the
concept of Linked Data from RDF. RDF is but an option, if you choose to
use RDF in a particular way.
We should use thing://data.totl.net/scooby to refer to the dog and
have a convention that http://data.totl.net/scooby will refer to some
content about my dog.
But that won't work in any of today's Web Browsers off the bat. Thus, it
doesn't solve the need for the transition to be none disruptive to user
experience.
This URL can of course then content negotiate as normal. You could
also use this in reverse. *thing*://www.imdb.com/title/tt0910554/ is
the primary topic of http://www.imdb.com/title/tt0910554/
It potentially works one way i.e., introspectively (to a point) from the
resource at: http://www.imdb.com/title/tt0910554/, if so crafted by the
publisher. It won't work from the Address bar of a Web Browser. It won't
work with cURL or wget etc. It just won't work from the client side.
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
