Re: Explaining the benefits of http-range14 (was Re: [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs) )

On 10/19/11 5:36 PM, Leigh Dodds wrote:
> Hi,
>
> On 19 October 2011 20:48, Kingsley Idehen<kidehen@openlinksw.com>  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