Re: RFC2396bis wording, opinions?

> Thank you for rubbing our noses in the paragraph about 'identifier.'
> That makes it clear that some of the current and past input has been
> ignored in this draft.

By "rubbing your noses", I assume you mean alerting folks to a
discrepancy between assumptions and what has actually been written
within the specification.  If folks commenting on the specification
would actually read it, and not just read the commentary of others
in response to specific sections, then I think there would be less
concern over definitional issues.  I understand that changes over
the course of multiple drafts will get lost in the noise, which is
why I pointed it out.

None of the current or past input has been ignored.  Some of the current
or past input has been factually incorrect and therefore not 
incorporated
in the draft.  Sorry, but "Al's opinion" is no more a measure of 
consensus
than "Roy's opinion", and running code always trumps opinion.  The only
time there is a real disagreement is when two different sets of code
do two different things and the authors can't agree which one is buggy.
At that point I ask them which one they would prefer, and they are
usually quite reasonable and agree to a single course of action, which
in turn is recorded in the draft.

If there is editorial disagreement about the meaning of a sentence
(not the meaning of a technology), then I generally use my own judgment
unless there is clear consensus in some other direction or my opinion
is overridden by the other authors.

> What some of us are trying to do is to cleanse the text, so that the
> heuristic portions surrounding the specification of the syntax and
> scheme-invariant
> operations on this syntax do not accidentally give the appearance that 
> there
> is a uniform way that URIs 'mean' which is actually narrower than the 
> range
> of appropriate practice, both current and anticipated.

mean != identify.  What I'd like to do is leave enough informational
text in the document so that people understand the technology that
they are implementing.  The reason is to reduce the number of crackpot
schemes that have been proposed to "fix" some imagined limitation
of existing URI schemes, and more of that type of advice will be
added to the next draft because RFC 2718 was informational and thus
impossible to obsolete.

> The "unique choice among a discrete field of choices" model presented
> above is, for example, just such a seeming uniform semantic model
> that doesn't fit either the current widespread use of search URLs
> for web-searching or GIS map panning, nor does it seem to fit well
> with the semantic integration of the as-is web with more and better
> semantic context through the Semantic Web.

What?  It explicitly disclaims any such uniform semantic model
within this document.  I cannot comprehend how you could read it any
differently.

> There are two ways to fix this that would appear to me to increase the 
> breadth
> of support for the RFC text:
>
> 1) use "identify or describe" for what URIs "are for."
>
> 2) relax the definition of 'identify' to something that clearly 
> includes indefinite references.

The definition already includes indefinite references, if what
you mean by that is the identifiers are late-binding.  The fact that
they are processed as a temporal-dependent mapping over a given data
set does not change the fact that the identifier does identify that
mapping, not the results from applying that mapping at some point
in time.  The same applies to all "http" URIs that support the GET
method with information-bearing results, regardless of how the URI
was composed.  That is why Larry proposed the "duri" scheme -- to
provide a mechanism for obtaining already-bound identifiers from
late-binding identifiers.

> I believe that the situation with web  searching should be dispositive 
> in terms
> of forcing us to accept that the discrete model is too narrow to fit 
> the Web.
>
> Web searching is very popular, believed by some to increase the 
> democracy
> of information access across the web, and I submit that the Web would 
> not
> have grown as far as it has without it.
>
> In web searching, the URI creator or emitter is a client, a user agent.
> The dialog here is not
>
> "I am interested in that thing you identified as 
> <http://www.example.com/search?q=foo>"
>
> but rather
>
> "Hi, <http://www.search.example.com>. I would be interested in
> anything that resembles the match-pattern '/search?q=foo'. What can 
> you tell
> me about such things?"
>
> The first synthesis of the full URI is on the part of the requester,
> not the party responding to the request. And it is not a definite
> identification of a pre-conceived notion, but a rough
> characterization of an indefinite curiosity.

That is consistent with what is already written in the draft.
The identifier distinguishes that query from all other potential
queries, and hence from many resources to one.  The resource is
not the query result.

> If this is all too philosophical for some, consider the transaction
> when you click on your MapQuest map to re-center the view. Here
> continuity with the prior view is as essential as the difference
> between the prior and successor views. The difference in server
> response between clicking on one pixel and the next is negligible, and
> it's important that it be so.

Yes, again this is consistent with the draft.

> Clearly the 'tdb' scheme proposal _imports_ rather than _creates_
> whatever allusion it recycles. If the intermediate resource contains
> an identification, then the tdb: URI denotes an identification. If
> the intermediate resource contains a description, that is what the
> tdb: URI passes along. Using a tdb: URI to re-use a relation anchored
> somewhere else does not upgrade the level of definition in the
> pre-existing identification or description relationship.

Right, which is consistent with what the draft already says.

> We had been at the point of consensing that we do not in this
> document wish to constrain what it is that a URI may relate to as its
> proper assocation. I hope I have explained that talking in terms of
> isolating one choice from a discrete field of choices is indeed
> restricting what can be at the end of a URI's denotational
> relationship; in a which matters and which disagrees with current and
> beneficial uses of URIs on the Web.

The definition provided in the draft does not say anything about
proper association or identity, aside from explicitly disclaiming
that it does say such things.  Isolating one choice, wherein that
choice might be "query results for some query", "coordinates on
this other map", or "that described by this other resource",
is the ONLY purpose for having identifiers.

   "An identifier embodies the information required to distinguish
    what is being identified from all other things within its scope
    of identification."

Please note that "all other things within its scope of identification"
is not in the least constraining or specific to any one type of URI,
nor does it assume definite or indefinite identification.

That is the meaning of the word identify for the sake of this document,
which is explicitly defined in that section because people keep assuming
that there is only one definition of identify in the English language
and that the document somehow disagreed with it.  My response to those
comments is to provide the definition that clarifies what the document
says so that there is no longer any room for ambiguity.

Is it possible that you simply misread the section?  I cannot understand
what it is that you are disagreeing with.  My only guess is that you
are assuming that URIs identify the results obtained from a specific
GET request, but that doesn't make any sense because we both know that
resource representations vary over time.  Indefinite URIs identify one
indefinite resource (the mapping), not an unknown set of definite
resources.

....Roy

Received on Tuesday, 1 June 2004 19:30:43 UTC