RE: definitions for operations on URIs

Hi Al,

Given that the message Larry referred to was from me, maybe I should say a
little a what motivated the original message.

The terms resolution, dereference and retrival all seem to get used in
conjunction with URI. I was enquiring whether there were fine-grain
differences in meaning in the use of such terms, and if so whether good
definitions existed already. 

The TAG (of which I am a member) have said things like "Dereferencing a URI
is safe", "Following a link is safe" or "retrival using HTTP GET is safe"
(for some concept of safety). But I think that we may have a loose or
different notions for what it means to dereference a URI. It is also evident
that the IETF is working on "URN resolution" (DDDS part 4) which seems
related.

The (virtual) world view that you present below, neatly avoids having to use
this terminology... which is nice. But the terms float around in common
usage, maybe ill-defined, and do percolate into such documents as TAG
findings and the emerging document on Web architecture.

> -----Original Message-----
> From: Al Gilman [mailto:asgilman@iamdigex.net]
> Sent: 14 July 2002 16:31
> To: Larry Masinter; uri@w3.org
> Subject: Re: definitions for operations on URIs
> 
> 
> 
> At 12:53 PM 2002-07-13, Larry Masinter wrote:
> 
> >http://lists.w3.org/Archives/Public/www-tag/2002Jul/0169.html
> >
> >These look like interesting possible additions to the URI 
> specification.
> 
> Interesting, if one could tell what they meant.

:-( ;-)
 
> >URI Resolution: 
> >  The process of determining the access mechanism and 
> >  appropriate parameters necessary to dereference a 
> >  URI. e.g. in the case of an HTTP URI, this process 
> >  resolves the URI into an IP address, a port number, 
> >  a host name (possibly optional) and a request URI.
> >
> >  Resolution may require several iterations.
> 
> The access mechanism is not necessarily unique.
> [example: HTTP 300 response; html:object element]
> Can't tell one is done with this until the intended
> query, be it to create, inspect, or modify "the state
> of the resource," (actually, some neighborhood in The Web) 
> has succeeded or one has exhausted options and none 
> has succeeded.

Ok... could change "...the access mechanism..." to "...an access
mechanism...".

In your response I find it interesting that (to you) resolution seems
involve some operation on the resource that needs to complete successfully
in order for resolution to complete successfully.

> >URI Dereference: 
> >  The process of using the access mechanism and 
> >  parameters generated by URI resolution to create, 
> >  inspect or modify resource state.
> 
> The nature of the desired operation may be implied
> by the URI itself or may be determined by the context
> in which the URI-reference is found.  The action 
> described here is the elaboration of a transaction 
> for which the URI is part of the initial representation.  
> The URI does not always contain all the assertions which 
> govern this concretion step.
> 
> >URI Retrieval: 
> >  The use of URI dereference to retrieve 
> >  representations of resource state. 
> 
> This language is circular.  Retrieval is to retrieve.
> But what is that?

Ok... its a fair cop...

> What is actually happening is creating a 'local' resource,
> that is to say a resource within an address space decided
> by and convenient for the using process, which is a faithful
> replica of the state of the resource and meets certain 
> concreteness or representation vocabulary constraints of the
> using process as well.  [Think endian flips.]
> 
>  From the 'defining' language given, it is not clear how
> to distinguish this from the previous.

So... the "'defining' language" arose from the existence of terms like
"deferencable URI" and "URN resolution" (cf DDDS part 4) and the association
of 'safety' with retrieval or dereference (depending on who one is listening
to) in common use.

What you present (here and below), and I have no problem with it, is a world
view that avoids notions of resolution, dereference and retrieval.

> And the 'create' and 'modify' cases would seem to
> call for terms parallel to this 'inspect' version.

I chose 'create', 'modify' and 'inspect' to avoid the use of PUT, POST, GET,
DELETE...

The reason to pick on retrieval as such is the expectation of 'safety'
assoicated with the retreival of state representations 
e.g. http://www.w3.org/2001/tag/doc/get7#safety, or
http://www.w3.org/2001/tag/2002/0701-intro#derefe"rence or perhaps
originally http://www.w3.org/DesignIssues/Axioms.html#state or the relevant
part of RFC2616 and its predecessors.

*If* "Dereferencing URIs is safe" is to mis-speak, what is it that should be
described as being 'safe'.

> Of course in the case of web Forms, what one retrieves
> is not just resource state but the opportunity including
> method handles to change the state.
> 
> These are all flavors of elaboration or expansion of
> a compact utterance:  migrating an expression in the
> specific direction employing through known, applicable 
> generic-specific relationship patterns.
> 
> A URI-reference constrains, but does not necessarily complete
> the constraints on, the fragment of the Web that is being 
> elaborated in this line of development.
> 
> The whole discussion is unfortunately tainted with network
> communication residues.  This is not necessary, and it is
> not the Architecture of the Web until this aspect is defined
> independently from network and database specifics.
> 
> What is happening is that there
> is a local web within which a neighborhood (a context+expression
> containing a URI-reference) is being expanded, and because
> of the embedded URI-reference, the expansion is being done
> subject to constraints linking the local expansion with a large, 
> persistent web in which URIs are globally non-colliding in their
> interpretation (to a sufficient degree).

I think thats a very nice picture.

> The URI serves to key the view into the persistent, shared Web with 
> which the local-web expansion is to be synchronized.
> 
> The 'done-ness' or stopping criteria for when the expansion has 
> succeeded are determined by the local transaction, not by the URI.

Yes... but there seem to be two 'levels' of activity here... the longer
running sequence of actions that result in further expansion and so-forth
which could go one for a while before one regarded the activity (buying some
shoes) as having concluded... and the more immediate expansion, keyed by URI
and some context, along with the immediate result of that 'single' expanding
step. It seems to me that there can be a sense of 'done-ness' at both these
levels.

> Al

Thanks,

Stuart

Received on Monday, 15 July 2002 08:10:20 UTC