Re: Issue-57

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.


Kingsley
>
>
> 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
>>
>>
>>
>>
>>
>>
>
>


-- 

Regards,

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