Re: Architecture Document: Terminology: Dereferencable, Retrivable, R esolvable.

I have used "dereference" to mean to "get that identified by" as in
dereferencing a pointer. The meaning here is I think
the same as your "retrieval, except that I prefer "dereference"
as it seems to me to be an abstract function -- the referent
as a function of the identifier, while 'retrieve" indicates motion
of something (as in a Labrador trotting back with a duck).

In a computer system, you can dereference something which
identifies a file or a document.

Tim


----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: <www-tag@w3.org>
Sent: Friday, July 12, 2002 10:58 AM
Subject: Architecture Document: Terminology: Dereferencable, Retrivable, R
esolvable.


>
> The retentive in me is coming out...
>
> In writing about the things folks might do with URI (and URI references)
we
> speak variously of resolvable, dereferencable and retrievable URI. However
> it's not clear to me whether or not we have consistent notions the
different
> shades of gray that might be associated with these terms. If there are
good
> pre-existing definitions for these notions a pointer would be welcome.
>
> For instance, a TAG finding might say that "All important resources should
> be identified using deferencable URI" (for example). One might take that
to
> mean that a representation of the resource should be 'retrievable' using
the
> relevant URI (that's what it says at [1]). But I think one could also
argue
> that any of HTTP PUT, POST, HEAD or DELETE involve "deferencing" the URI.
In
> programming languages we apply the notion of dereference wrt to an object
> reference or a pointer regardless of whether it is used on the left or
right
> hand side of an assignment. So... whilst to be 'retrievable' a URI must
also
> be 'deferencable' the act of 'derefencing' a URI does not necessarily
imply
> a safe 'retrival' operation. Likewise, to be 'dereferencable' a URI must
> also be 'resolvable', the act of 'resolving' a URI being a pre-cursor to
and
> possibly entailed within the process of dereferencing a URI.
>
> Does this make any sense or do such fine grain differences not matter in
our
> architectural writings?
>
> Anyway, some proto defintions to chew on:
>
> 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.
>
> URI Dereference:
>   The process of using the access mechanism and
>   parameters generated by URI resolution to create,
>   inspect or modify resource state.
>
> URI Retrieval:
>   The use of URI dereference to retrieve
>   representations of resource state.
>   [On the Web Retrival is always safe].
>
> Comments?
>
> Regards
>
> Stuart Williams
>
> [1] http://www.w3.org/2001/tag/2002/0701-intro.html#dereference
>

Received on Monday, 15 July 2002 14:47:06 UTC