Use of "assign" for URI -> resource

I think some edits got made, but there are still some
residual uses of the word 'assign' in the document for
the process by which URIs get meaning that I think still
need to be reviewed.

First, although section 2.2.1 is now called 'URI allocation',
there are still some cross-references that say 'URI assignment'

Constraint: URIs Identify a Single Resource
  "Assign distinct URIs to distinct resources."
  => "Use distinct URIs for distinct resources."

For example, file:///etc/hosts is a single URI which could
be used by different people to mean different resources.
We can't change the fact that they're assigned, but you
shouldn't USE them. The 'file:' URI scheme means what it means.


Similarly,

"To avoid URI collision, it is important to avoid assigning
  the same URI to different resources."
becomes 
   "... avoid using the same URI for different ..."


=======================

Related, an old topic, but one that I am not sure was
really ever resolved (except perhaps that the solution
seemed like it was too hard). So I will take another
pass at this...

I think section 2.2.1.1., labeled "URI ownership"
could be renamed. Resources have owners. URIs have
users. The owners of resources arrange the resources
so that URIs can be used to identify the resources
and their related resources.

I'd suggest

# 2.2.1.1 Resource Ownership and Delegated Allocation

# Many URI schemes are used to described resources
# where there is an 'authority' component in the URI
# scheme, such that the authority component of a
# URI names a social entity responsible for those
# resources and the allocation of URIs to them. This
# is the case for "http", "mailto", "ftp", and "urn".
# In some cases, the authority is delegated to others,
# e.g., to server managers or someone who has been
# given part of the URI space on a given Web server.

This gets rid of the notion that the social entity
owns the URIs: it owns the resources, which makes
more sense.

I think it's possible to eliminate "URI ownership"
in the rest of the document fairly easily.


"A URI owner may, upon request, provide representations
 of the resource identified by the URI. For example, when
 a URI owner uses the HTTP protocol to provide those 
 representations, the HTTP origin server (defined in 
 [RFC2616]) is the software agent acting on behalf of
 the URI owner to provide the authoritative representations 
 for the resource identified by that URI. The owner is also
 responsible for accepting or rejecting requests to modify 
 the resource identified by that URI, for example, by configuring
 a server to accept or reject HTTP PUT data based on Internet 
 media type, validity constraints, or other constraints.


I think this is best rewritten by making it the
resource that is owned, not the URI.

# The owner of a resource may arrange the resources
# such that a URI can be used to obtain representations
# of the resource identified by the URI. For example, when
# a resource owner offers the HTTP protocol ...
# ... on behalf of the resource owner to provide ...


> Recall that Web architecture allows different URI owners to 
> create URI aliases. 

Actually, this is a forward reference, so 'recall' is
inappropriate.  I don't think it is 'the Web architecture'
that allows this, in the sense of this document.

# Recall that it is possible for there to be URI aliases:
# different URIs for the same resource.

> There are social expectations for responsible representation
> management [section 3.6] by URI owners, discussed below. 
> Additional social implications of URI ownership are not
>  discussed here. However, the success or failure of these 
> different approaches depends on the extent to which there is 
> consensus in the Internet community on abiding by the
> defining specifications.

I think this works fine changing "URI owners" to
"resource owners".

> A URI owner SHOULD NOT associate arbitrarily different URIs with the same
resource.

I think this makes little sense as stated, and is
much more effective changing 'URI owner' to 'resource owner'.

> When a URI alias does become common currency, the 
. URI owner should use protocol techniques such as
>  server-side redirects to relate the two resources. The 
> community benefits when the URI owner supports redirection 
> of an aliased URI to the corresponding "official" URI...

...

> the URI owner is free to configure the server to return ...

> Resource state may evolve over time. Requiring a URI 
> owner to publish a new URI for each change in resource state...

> Whether the URI owner makes available any representations at all...
> If the URI owner has provided more than one representation ...

> Dirk and Nadia conclude that the URI owners are ...
> Although the URI owner has chosen the Web as a communication medium, 
> they have lost two customers due to ineffective resource management.

> URI persistence is a matter of policy and commitment on the part of 
> the URI owner. 



'URI owner' => 'resource owner' is a great improvement in
all of these.

> A URI owner may supply zero or more authoritative representations 
> of the resource identified by that URI. ...
> A URI owner SHOULD provide representations of the identified resource.


# A resource owner may supply zero or m... of the resource at
# the URI allocated for the resource. ...
# A resource owner SHOULD provide representations of a resource
# at the URI allocated for it.

Finally, for the last use of 'owner':

> ... namespace URI owner ...

I think this is OK, and you can leave it.


Larry
-- 
http://larry.masinter.net

Received on Thursday, 16 September 2004 00:22:41 UTC