Re: Introduction / Position

Thanks for this - it gives me something to disagree with.

Overall I think we need to focus on interoperability and other
engineering goals. Architecture and philosophy are just tools for
achieving some end, and we've got to keep our eye on the ball.

A rule we've adopted in this group - that I forgot to tell you about -
is that each use of a term has to be clearly bound to a definition,
either by reference (URL or whatever) or locally (as in "I'm using
'foo' in the following way: ..."). This is especially true for
troublesome terms like "resource," "representation," and "information
resource", each of which already has multiple mutually incompatible
published definitions.

Rather than introduce another definition for a term that's already in
use, it's usually better to mint a new term, in case the binding of
use to definition gets confused (as it often does).

Terminological turf wars are deadly for the kind of analysis we need
to do here, so we have to try hard to avoid them, and that's what the
rule is designed to do.

E.g. it's not completely clear in what you wrote whether you are
introducing a new definition for the word "resource", or if you think
that what you wrote follows from some already published definition.

Best
Jonathan

On Sun, Jan 16, 2011 at 7:10 PM, Nathan <nathan@webr3.org> wrote:
> Hi All,
>
> Here's some text which describes my current thinking, and which will
> essentially form the basis of any feedback I give in relation to the topics
> discussed by this group:
>
> [[[
> The set of things which URIs can name are called Resources in web
> architecture.
>
> Resources are the key abstraction in web architecture, each resource is a
> conceptual mapping to a set of entities, not the entity that corresponds to
> the mapping at any particular point in time.
>
> The term "resource" is itself a name for a resource, a conceptual mapping to
> the set of all things which can be referred to, used by, interacted with, or
> presented by machines - not the contents of this set at a particular point
> in time.
>
> Since technological advancements are constantly being made, it is impossible
> to effectively define or constrain the set of things which are resources; as
> such, it is impossible to define or constrain the set of things which can be
> referred to by URIs.
>
> URIs are human and machine friendly names which are used to refer to
> resources, they are references to a conceptual mapping.
>
> The ways in which a resource referred to by a particular URI can be used,
> interacted with or presented are not defined or constrained by the lexical
> format of the URI, nor the specification relating to the scheme of the URI,
> nor any protocol relating to the scheme.
>
> The ways in which a particular URI can be dereferenced are not defined or
> constrained by the lexical format of that URI. When the scheme of a URI
> relates to a protocol, then this is merely an indication of a well defined
> protocol which may be used as part of a dereferencing process.
>
> The method of dereferencing a URI and the result of any dereferencing
> action, is determined entirely by the application doing the dereferencing.
> That is to say, the result of dereferencing a URI is entirely context
> specific, different applications may implement entirely different methods of
> dereferencing the same URI, producing entirely different results.
>
> Each resource has an unbounded set of names, and that set of names can
> change at any time. As such, no name is the name for a resource, rather it
> is a temporary name for that resource.
>
> A name which refers to one resource at a particular instant may refer to an
> entirely different resource the next instant. Moreover, at any given instant
> the same name may be used in different contexts to refer to entirely
> different resources.
>
> As URIs are names, they share the ambiguities and characteristics of real
> world names, similarly as resources are conceptual mappings, they too share
> the same ambiguities and characteristics of real world conceptual mappings.
>
> The lexical form of a URI does not have any universal significance, however
> both humans and machines are free to derive some indication of the thing
> being referred to from information derived from the lexical form of a URI,
> this is merely a belief state, which can be, and often is, invalidated by
> the act of dereferencing that URI.
>
> URIs are both opaque strings and compound names, each component part of a
> URI is potentially a name for a distinct resource. URI syntax is constructed
> in such a way that the temporal variance and stability of the resource
> referred to by each component part increases exponentially from left to
> right.
>
> The component parts of a URI are typically utilized within scheme specific
> processing of that URI, all except the tail component, the fragment
> identifier, which is separated from the rest of a URI prior to scheme
> specific dereferencing.
>
> Whilst fragment identifiers are abstracted from the rest of a URI as part of
> scheme specific dereferencing, they play an important part in the
> dereferencing processing. Fragment identifiers enable, and are utilized by,
> secondary/layered protocols, and applications in the context specific
> dereferencing of a URI.
>
> URIs containing fragments are often considered to name secondary resources,
> a resource only indirectly referenced by a primary resource, however this is
> only a technical constraint placed on first class transfer protocols to
> allow the process of dereferencing to be extensible, layered and context
> specific.
>
> The presence of a fragment within a URI is not an indication that the URI
> names a "secondary resource", or that any "primary resource" exists. Each
> URI is an opaque name for a resource, no hierarchy between names or
> resources is inferred or indicated by the syntax of that URI. That is to
> say, the act of dereferencing involves taking a single opaque name, and
> dereferencing that opaque name. The successful dereferencing of an opaque
> name is not an indication that a URI comprising a subset of the component
> parts refers to any resource, or indeed that it is a name for anything.
>
> Since all URIs are temporary references to conceptual mappings, they are
> not, and cannot be, persistent identifiers. Persistent identification can
> only be achieved via unambiguous representation or description of the
> identity of a thing, and shared understanding of that representation or
> description. Persistent identification cannot be by reference.
>
> Persistent identification is beyond the scope, and possibility of URIs in
> Web Architecture. If entities require that a name be used as a persistent
> identifier within certain contexts, then it is the responsibility of that
> entity to ensure that any usage of that name within those contexts is
> consistent, with a well defined, shared meaning, this entails ensuring that
> the dereferencing of that URI within those contexts remains consistent and
> available over time. This is in the realm of the application, not the
> architecture.
>
> Additionally, as URIs are temporary references to conceptual mappings, it is
> possible for a URI to refer to one conceptual mapping valid at time t1 in
> one context, and another conceptual mapping valid at time t2 in another
> context. As such, it is possible for URIs including a domain name to refer
> to a conceptual mapping defined by a previous owner of that domain in
> certain contexts. Thus, the presence of a domain name within a URI does not
> indicate legal ownership, or responsibility, over that URI by any entity
> currently owning that domain name.
>
> However, entities are legally responsible for things they say and do, and as
> such can be held accountable for any action they take, or information they
> provide, in response to a dereferencing action.
>
> As of 2011, there remains much research and standardization work to be done
> in this respect, particularly with regards to the accountability and
> provenance of messages sent over the internet as a result of, and in
> relation to, a dereferencing action.
>
> ]]]
>
> Hopefully that all makes sense, and once again, thanks for inviting me to
> comment.
>
> Best,
>
> Nathan
>
>

Received on Tuesday, 18 January 2011 01:03:55 UTC