W3C home > Mailing lists > Public > public-webarch-comments@w3.org > October to December 2004

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

From: Stuart Williams <skw@hp.com>
Date: Mon, 11 Oct 2004 16:39:27 +0100
Message-ID: <416AA92F.1020707@hp.com>
To: Larry Masinter <LMM@acm.org>
Cc: public-webarch-comments@w3.org

Hello Larry,

At our F2F meeting on 5-7th October the TAG [1] discussed your comments, 
below.

The net of our discussions is that that TAG were not persuaded to make 
the replacement of  "Assign" with "Use" which you requested, nor were we 
persuaded to "eliminate" the concept of "URI Ownership".

Please can you indicate whether or not you can live with the text as it 
is in the current editors draft [1], which retains "assign" rather than 
"use" and which retains concept of "URI ownership" although the 
narrative [2] has changed from that of the 2nd LC draft.  There is a 
pending edit to move/remove the data URI scheme example from that section.

Many thanks,

Stuart Williams
On behalf of W3C TAG.
--
[1] http://www.w3.org/2001/tag/webarch/
[2] http://www.w3.org/2001/tag/webarch/#uri-assignment
[3] http://www.w3.org/2004/10/05-tagmem-irc

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.
>  
>
The TAG was not persuaded to make the change that you requested -  from 
the IRC log of our meeting record of 5th October [3]

13:21:37 [DanC_]
    PROPOSED: to keep " Constraint: URIs Identify a Single Resource
    Assign distinct URIs to distinct resources." despite the new
    information from LMM's comment 
13:22:53 [DanC_]
    2nded 
13:22:58 [scribendw]
    by TBL 
13:23:12 [Chris]
    ok by me 
13:23:38 [timbl__]
    TBL: I don't htink there are any schemes I can think of now where we
    need to make sure that people don't use the same URI for different
    things and there isn't allocation going on.... and there is any
    question of what the URI identifies. 
13:23:42 [timbl__]
    above 
13:24:06 [scribendw]
    Accepted. RF abstains. 
13:24:13 [scribendw]
    ACTION: SW to tell the commenter 

>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.
>  
>
The text of section 2.2.1.1 the current editors draft [1] has been 
revised - and further edits are pending based on decisions we made at 
the F2F. However, the TAG was not persuaded to "eliminate 'URI 
Ownership' in the rest of the document.  From the IRC log of our meeting 
[3].

13:43:57 [Roy]
    PROPOSAL: The TAG uses the term URI ownership rather than resource
    ownership because some URIs identify resources that the URI owner
    (a.k.a., minter) does not own. For example, when a URI identifies a
    physical object that is merely named by the URI owner. 
13:44:14 [DanC_]
    2nd 
13:44:43 [scribendw]
    Accepted. 
13:44:44 [Chris]
    ok 
13:45:07 [scribendw]
    ACTION: SW to make this response to Larry


>"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 ...
>  
>
This has been re-written in the editors draft, but not with the intent 
of eliminating the concept of URI Ownership.

Since the intent of many of the proposed edits below are to remove the 
concept of URI ownership and the TAG were not persuaded of that intent, 
we did not consider them in detail.

>>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
>  
>
Received on Monday, 11 October 2004 15:39:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:47 UTC