- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 24 Jun 2011 07:56:10 +0100
- 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. 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