W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2011

Introduction / Position

From: Nathan <nathan@webr3.org>
Date: Sun, 16 Jan 2011 19:10:26 +0000
Message-ID: <4D3342A2.9040009@webr3.org>
To: AWWSW TF <public-awwsw@w3.org>
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 

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 

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.


Received on Sunday, 16 January 2011 19:12:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC