Re: Use of "assign" for URI -> resource

Hello Larry,

I have also made some comments relevant to Section 2.2.1.1 which head in 
a different direction wrt to "URI Ownership". Your feedback on those 
would be welcome [1]

The direction you offer is largely to dispense with the concept of "URI 
ownership" and shift the emphasis toward ownership to resources. I made 
a stab at framing "URI Ownership" in terms of the rights and 
responsibilities of  "URI owners".  I have some difficulty accepting 
that there is not a sense in which at least some URI are owned, and its 
clear that not all resources are own - so we cannot say generally that 
it is resource owners that make assignment of a URI as an identifier of 
a resource - eg. the planet Mars.

BTW:  I also get vexed with the number of different words that we get 
prefixing or post fixing "URI", which are synonymous and which are not.

URI Allocation: a transfer of ownership rights over one or more URI to 
some social entity (which can include scheme specifications) - an act of 
delegation in URI space.
URI Assignment: the association of a URI with the resource it identifies 
(a right exercised by the owner of the URI) - the piece meal 
construction of the "identifies(URI x Resource)" relation.

More commentary below.

Best regards

Stuart
--
[1]  
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0061.html

Larry Masinter wrote:

>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.
>  
>
Is there not some entity that obtains a right to make an association 
between a given URI and a resource? Such rights may come to them through 
some delegation chain rooted in the URI spec. and the IANA scheme registry.

It's also not clear that all resources have owners. If resources is 
scoped so large as to includes say planets or galaxies, I'm not sure I'd 
be able to attribute any particilar owner to say the planet Mars - 
though I guess some may stake a claim :-). However, I may have rights in 
some sense to associate the URI http://example.org/planets/Mars or 
http://example.org/planets#Mars with the planet Mars in such away that 
one or both of those URI are said to identify (in a denotational sense) 
the planet Mars.

I might then want to back this up by making available representations of 
the planet Mars to anyone who happens to dereference one or both of 
those URI. Of itself that exposes another conuderum... by deploying 
representations have I :

1) magically turned Mars (which I do not own) into an information resources.
2) deployed a new information resource (which I do own) that then stands 
proxy for the planet Mars, and gives me the grief that I may want to 
speak independently of the proxy and the planet.
3) been entirely misguided and the URI (either of then) never identified 
the planet Mars in the first place.

Anyway...  would you claim any rights over the URI based on the DNS name 
"larry.masinter.net" (not the resources they identify, but the URI 
themselves) ? 

>I'd suggest
>
># 2.2.1.1 Resource Ownership and Delegated Allocation
>
># Many URI schemes are used to described resources
>  
>
                                                                  ^^^^^^^^^
URI schemes "describe" resources? Maybe - "describe" doesn't feel like 
the right verb.

># 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.
>  
>
Broadly like this preamble.

>This gets rid of the notion that the social entity
>owns the URIs: it owns the resources, which makes
>more sense.
>  
>
I can't see that it is necessarily the case that all resources have 
owners, and I'd be willing to concede that not all URI have owners. 
However, I think that, socially, we vest ownership of the URI space in 
the IANA registry and the social process (es) that result in the 
inclusion of scheme specifcations in that registry. In a sense, when a 
scheme is registered, ownership of that chunk of a URI space passes to 
the registered scheme specification (and the community that maintains 
it)... and the scheme specification itself my further delegate ownership 
to other registry/specification combinations (eg. URN namespaces) and/or 
organisations, roles within the organisation and so-forth.

>I think it's possible to eliminate "URI ownership"
>in the rest of the document fairly easily.
>  
>
You used the word "use" above with respect to URI has a very egalitarian 
feel to it in the sense of there being no primacy of use. That seems to 
me to work as far as a "USE" of a URI is it's occurence in 
representations or as a protocol element or written on a piece of paper.

But "USE" does not establish who/what gets to form an association 
between a URI and the resource it identifies (either operationally [*] 
or denotationally [#]).

[*] operationally in the sense of following the documented mechanisms 
for dereferencing URI - which I believe is the way you use the word 
identify.
[#] denotationally in the sense of folks using URI to name things in the 
world (like planets) - which I believe is also a way in which the word 
idenify is used. When a URI identifies what it is used to denote then 
there appears to be a level of harmony (modulo some discussion of 
whether its denotation is an information resource/hypertext dispenser or 
the thing that described or depicted by that information resource).

>"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 ...
>  
>
Can you explain how this would work for the planet Mars?

>>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'.
>  
>
I think this makes it a little difficult to associate a URI with a 
resource like the planet Mars (that may be deliberate).

>>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
>  
>

Received on Thursday, 16 September 2004 11:12:42 UTC