On 10/19/11 5:36 PM, Leigh Dodds wrote:
Hi,On 19 October 2011 20:48, Kingsley Idehen<[email protected]> wrote:On 10/19/11 3:16 PM, Leigh Dodds wrote: ....But you don't have two different resources. Please correct me if I am reading you inaccurately here, but are you saying that: http://dbpedia.org/resource/Linked Data and http://dbpedia.org/page/Linked Data == two different resources? I see: 1. 2 URIs 2. a generic URI (serving as a Name) and a purpose specific URI called a URL that serves as a data access address -- still two identifiers albeit split by function .RFC3983: "A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."Yes, I agree with that.2 URIs, therefore 2 resources.I disagree with your interpretation though.But I'm not interpreting anything there. The definition is a URI identifies a resource. Ergo two different URIs identify two resources.
Two different URIs do not necessarily identify two different resources.In the case of Linked Data, you have URIs that put indirection to use. Thus, You have different identifiers that resolve to the same data. This data is streamed from server to client, and the actual data representation is negotiable (explicitly or implicitly).
A data object is endowed with Identity distinct from its representation. This is the crux of the matter, and ultimately our debate boils down to whether the statement above is proven to be a computer science fact or fiction. There's now gray area re. this matter.
If you seek the representation of the description of 'Linked Data' that takes the form of an EAV/SPO based graph pictorial you have the following routes to the aforementioned data, re. DBpedia:
1. http://dbpedia.org/resource/Linked_Data --- generic name 2. http://dbpedia.org/page/Linked_Data -- location name (address)#2 will deliver an HTML based representation of the data that constitutes the EAV/SPO based description. The identity of the data object (resource) remains intact.
Hence: curl -I http://dbpedia.org/resource/Linked_Data HTTP/1.1 303 See Other Date: Thu, 20 Oct 2011 00:26:59 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Server: Virtuoso/06.03.3131 (Linux) x86_64-generic-linux-glibc25-64 VDB Accept-Ranges: bytes Location: http://dbpedia.org/page/Linked_Data Content-Length: 0 Demonstrating that: indirection has occurred via HTTP message exchange.Now let's say we were dealing with a # style of URI, the indirection still happens, it just does take place via HTTP message exchange. That's what makes it less expensive, and ultimately why the hash vs slash matter is a linked data publisher implementation detail.
By definition and implication, indirection is about indirect access to a final destination. In this case the place/location/address where the server publishes data.
Whether those resources might be related to one another, or even equivalent is an entirely different matter.Identifiers are names / handles. Thus, you have Names that resolve to actual data albeit via different levels of indirection. http://dbpedia.org/resource/Linked_Data and http://dbpedia.org/page/Linked_Data are routes to different representations of the same data. /resource/ (handle or name) is an indirect access route while /page/ is direct (address i.e., a location name) albeit with representation specificity i.e., HTML in the case of DBpedia. I am very happy that we've been able to narrow our differing views to something very concrete. Ultimately, we are going to arrive at clarity, and that's all that matters to me, fundamentally.*That* all seems to be interpretation to me.
Maybe, the good thing is that we have a clearly established point of disagreement. Not a problem of course, but absolutely the best way to ultimately put this matter to bed, once and for all :-)
Cheers, L.
-- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
