- From: Xiaoshu Wang <xiao@renci.org>
- Date: Fri, 24 Jun 2011 02:01:53 +0000
- To: Kingsley Idehen <kidehen@openlinksw.com>, "www-tag@w3.org" <www-tag@w3.org>
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. This descriptive difference is not import. What is important is this: Can I give a Person an Address in the Web? I think so. TAG thinks not. Or do you think everything can have an address in the Web, or just some of them? 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 > > > > > >
Received on Friday, 24 June 2011 02:02:23 UTC