Re: RFC2396bis wording, opinions?

At 4:34 PM -0700 5/28/04, Roy T. Fielding wrote:
>Being minimalist just means that everyone gets to define it their
>own way, which is fine as long as it doesn't interfere with
>interoperability and doesn't imply one distinction by absence
>of others.  As such, I think the following wording is less likely
>to cause me additional work in the future, because it doesn't
>remove all of the examples which were explicitly requested by
>prior reviewers to avoid the assumption that their absence meant
>they were excluded from the definition.
>
>    Resource
>       This document doesn't limit the scope of what might be a resource;
>       rather, the term "resource" is used in a general sense for whatever
>       might be assigned a URI for the sake of later identification.
>       Familiar examples include an electronic document, an image, a
>       service (e.g., "today's weather report for Los Angeles"), and a
>       collection of other resources. A resource is not necessarily
>       accessible via the Internet; e.g., human beings, corporations, and
>       bound books in a library can also be resources. Likewise, abstract
>       concepts can be resources, such as the operators and operands of a
>       mathematical equation, the types of a relationship (e.g., "parent"
>       or "employee"), or numeric values (e.g., zero, one, and infinity).
>
>Since this also seems to be a frequent point of confusion, I will repeat
>what we mean by identifier and identification, as is already present
>in draft 05:
>
>    Identifier
>       An identifier embodies the information required to distinguish
>       what is being identified from all other things within its scope of
>       identification. Our use of the terms "identify" and "identifying"
>       refer to this process of distinguishing from many to one; they
>       should not be mistaken as an assumption that the identifier
>       defines the identity of what is referenced, though that may be the
>       case for some identifiers.
>
>This is my interpretation of the input received so far, taking into
>account both the current discussion and the others that preceded it.
>If you feel that the above text does not provide an adequate
>representation of consensus, then please let me know.
>[By that, I mean it reflects the meaning that people have described,
>not necessarily the words that they used to describe them.]

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.

I'm not going to try to assess the line between unanimity and rough
consensus.  The authors and IETF powers that be can wrestle with
that divination.

Let's start by re-iterating what I think has a solid consensus behind it:

<quote cite=
"http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-05.txt">

Abstract

    [...]  This
    specification defines the generic URI syntax and a process for
    resolving URI references that might be in relative form, along with
    guidelines and security considerations for the use of URIs on the
    Internet.

    The URI syntax defines a grammar that is a superset of all valid
    URIs, such that an implementation can parse the common components of
    a URI reference without knowing the scheme-specific requirements of
    every possible identifier. [...]

</quote>

It is a good thing this document doesn't try to specify uniform semantics
beyond the scheme: preamble structure that allows many patterns of
practice to intermingle, and the common processing of utility 
syntactic patterns.

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.

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.

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.

An example of the second approach would be to re-phrase the 
'identifier' discussion
as follows

<draft
class="change example">

OLD:

>    Identifier
>       An identifier embodies the information required to distinguish
>       what is being identified from all other things within its scope of
>       identification. Our use of the terms "identify" and "identifying"
>       refer to this process of distinguishing from many to one; they
>       should not be mistaken as an assumption that the identifier
>       defines the identity of what is referenced, though that may be the
>       case for some identifiers.


NEW:

>    Identifier

As an identifier, a URI collects and encodes information useful to distinguish
something associated with this character sequence used as a URI from things
associated with other URIs.

</draft>

I for one could be just as comfortable if we use 'identify' in the
discrete sense and make clear that sometimes URIs 'identify' and sometimes
they 'describe.'

<discussion>

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.

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.

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.

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.

</discussion>

I hope that this explains my heartburn with this attempt at consensus.

For what it's worth, this input is not new.

[1] http://lists.w3.org/Archives/Public/uri/1997Oct/0006.html

[2] http://lists.w3.org/Archives/Public/uri/2001Nov/0047.html

Al

>Cheers,
>
>Roy T. Fielding                            <http://roy.gbiv.com/>
>Chief Scientist, Day Software              <http://www.day.com/>
>
>p.s., as Mike just mentioned, the uppercase I in Internet is intentional
>       because this is a Draft Standard for the Internet, and hence the
>       concern was that people would assume it only applied to Internet
>       accessible resources.  Anyway, that sentence has 10 years of
>       history that I seek not to repeat again.

Received on Tuesday, 1 June 2004 16:16:18 UTC