Re: lack of consensus on httpRange-14

At 11:52 AM 10/3/02 -0400, Simon St.Laurent wrote:

>In reading the minutes for the September 24th & 25th meeting, I found
>this morsel:
>------------------------------
>     TB: I propose that httpRange-14 be
>     de-prioritized. Two reasons (1) no consensus
>     (2) I don't think it affects the arch doc. I
>     would be amenable to close this issue with no
>     action.
>     DC: I agree with TB that httpRange-14 can be
>     closed with no impact on the arch doc.
>     RF: When you access a resource for today's
>     weather in Vancouver, and you get back info
>     that says "it's sunny", how do you know that
>     it doesn't mean "it's sunny everyday in
>     Vancouver." When you access a resource, you
>     need to be able to make assertions about the
>     resource and also representations of the
>     resource.
>     Resolved: "Defer" httpRange-14 with no action.
>     Objection: TBL.
>--------------------------------
>
>I'm not sure that "lack of consensus" is an appropriate reason to
>de-prioritize an issue which (at least from my perspective) lies at the
>heart of an enormous number of conflicts regarding the proper use of
>URIs.  While it may be possible to keep those conflicts from spilling
>directly into a vaguely-worded architecture document, they aren't going
>to go away easily.
>
>Might I suggest instead that the TAG close this issue, noting that
>consensus is not possible, and acknowledge the implications of that lack
>of consensus in other work?
>
>That may seem to weaken the general usefulness of URIs, but the weakness
>is already present - this would be acknowledging the problem rather than
>deferring it to future visions of solution.

I noted that discussion, and was tempted to respond.  Now I shall.

I think that, maybe, consensus *is* possible.  At least, I don't think 
we've yet exhausted the possibilities around which consensus may form.

In particular, I understand that the concern with not restricting http: 
URLs to documents is that it introduces ambiguity between a non-web object 
(e.g. my Car) and a web page that describes it.

In some of my work, I have avoided this problem (somewhat accidentally) by 
having multiple HTTP: URIs that dereference the same web page, but with 
different intent;  e.g.

   http://id.ninebynine.org/people/gk/

is defined to identify to me, the person, but

   http://www.ninebynine.org/Ident/people/gk/

is defined to identify the web page that describes the identifier URI.

In each case, the representation retrieved when dereferencing the URL is 
identical.  But (at least to my mind, as defining authority for the URIs) 
there is no ambiguity concerning what each URI actually identifies.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 3 October 2002 16:27:27 UTC