W3C home > Mailing lists > Public > www-tag@w3.org > June 2011

Re: Issue-57

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 24 Jun 2011 07:56:10 +0100
Message-ID: <4E04350A.9020808@openlinksw.com>
To: www-tag@w3.org
On 6/24/11 3:01 AM, Xiaoshu Wang wrote:
> Kinsley:
> You have only stated there are address/names. But it is no different from
> httpRange-14 because
> When a URI is an Address in your terminology, it means that the URI
> references a IR in httpRange-14.

Yes, and if it does, its is an Address since:

IR = Resource = Data, at an Address (a named Location).
> This descriptive difference is not import. What is important is this:
> Can I give a Person an Address in the Web?

You give the Address of a Resource that bears (carries) the 
representation of a Person.

Re. Linked Data such a resource would take the form of an EAV/SPO 
(3-tuple) graph pictorial, for instance.

>   I think so. TAG thinks not.
> Or do you think everything can have an address in the Web, or just some of
> them?

Object Representations have Address.
Object Names are not Addresses but, they can be minted using HTTP URI 
just like Addresses. Hence, the confusion.

> Xiaoshu
> On 6/23/11 5:41 PM, "Kingsley Idehen"<kidehen@openlinksw.com>  wrote:
>> On 6/23/11 4:08 PM, Xiaoshu Wang wrote:
>>> The original purpose of httpRange-14, I guess, is to avoid ambiguity.
>>> But
>>> ambiguity can only be cleared with more ontological assertions.
>>> httpRange-14 has raised more confusion/debate. Except transferring
>>> ambiguity to a different term, what problem it has solved?
>> Let me try:
>> Ambiguity sources:
>> 1. eradication of URL from lexicon such that we only speak of URIs since
>> a URL is subClassOf URI
>> 2. use of HTTP URIs as Names that may or may not resolve.
>> Problems:
>> The items above adds obscurity to an already obscure subject because
>> end-users and developers are familiar with URLs and how they function as
>> Resource Locators (Addresses). Thus, doing a two-fer that equates to:
>> 1. using URLs as generic Names;
>> 2. taking URL out of lexicon,
>> results in the quandary that http-range-14 is attempting to address.
>> Flip this all around, and the quandary remains. Again, let do another
>> two-fer:
>> 1. using URIs (URL out of lexicon) as generic Names;
>> 2. using URIs as Resource Locators ,
>> same difference as per earlier comment. Simply stating that 200 OK
>> implies a document doesn't deliver clarity.
>> A suggestion, that I think could really help.
>> AWWW fundamental goal:  Objects have Names and Representation Addresses.
>> Names and Addresses imply specific functionality. An Object Name
>> Identifies an Object while an Object Address is how you access its
>> Representation. Basically, you have a Name&  Access functionality
>> combined.
>> HTTP uses 200 OK to basically confirm that an Address is functional with
>> regards to user agent access to a given Resource. It is also safe to
>> assume and infer that 200 OK is also a way of stating that:
>> 1. a URI Names and Address
>> 2. a URI is of type URL (so this is a specific type of URI, the kind
>> that combines Name and Address/Access functionality)
>> 3. a URI that resolves directly to a Resource (data).
>> HTTP uses 303 (in particular) to confirm that a URI isn't an Address (if
>> it was it would 200 OK). Thus, if it isn't an Address it is a generic
>> Name. Basically, 303 delivers good old indirection functionality, and
>> via this functionality you can use URIs as Names that resolve to
>> specific Resources via>  1 level of indirection.
>> What's this really about, ultimately? Reasserting the fact that you can
>> use URIs for generic Names or Addresses (Resource Locators). To the Web
>> end-user and Developer, it means you can use hyperlinks for the following:
>> 1. Naming Things
>> 2. Locating Resources
>> 3. Naming Things in such a way that Names resolve to Resource(s) bearing
>> (carrying) representation(s) of their referents.
>> I hope this helps. I've never found this matter confusing, but I've
>> always struggled with http-range-14 narratives based on the fact that
>> its doesn't provide anecdotes that resonate with its target audience --
>> Web developers or end-users.
>> -- 
>> Regards,
>> Kingsley Idehen	
>> President&   CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Friday, 24 June 2011 06:56:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:10 UTC