The specific goals of this document are thus:

• To define a consistent behaviour for a non-hierarchical arrangement of URIs within the scope of a Web application;
• To aid with the naming of URIs and categorization of resources through appropriate constraints and affordances;
• To provide information architects with ad-hoc tools to explore and augment the structure of a Web site; and
• To allow power users to navigate Web site through direct URI manipulation.

principles include

• individual resources should be accessible in as many ways as conceivable
• every resource must be identifiable by the shortest URI path that unambiguously points to it
• the most specific URI that unambiguously identifies a given resource must be taken as canonical
• The system should be superficially indistinguishable from a conventional hierarchy in the absence of the expanded syntax
• The system should gracefully handle namespace collisions, renames, and deletions

a resource, e.g. a document, begins with at least one symbolic name, either explicitly assigned or by derivation of the title

this is an unqualified name equivalent in scope to a filename or xml ncname

when represented in the uri, the name is exactly what appears after the last slash in the path and before the first path parameter or query string

if there exist two or more resources with the same symbolic name, they will collide, and must somehow be qualified to be uniquely addressed.

to qualify resources, we place them into sets which are resources as well, and which have the same naming rules, i.e. if a set cannot be uniquely addressed, it is placed into a superset.

these sets are addressed as the part between the first (in-scope) and last slash of the uri path

the master set is that which contains every resource within the application, usually (but not always) the root of the path

up to now this effectively describes a conventional hierarchical layout

the key difference is that resources, that is to say either documents or sets, may belong to more than one set, or, providing there is no collision, the master set itself. this structure affords faceted navigation and multiple entry points to a given resource.

this also affords us the ability to remap the path separator / to signify set intersection.

the result of an intersection A ∩ B where B ⊆ A is B, which is effectively a no-op and therefore the intersection can be used to safely qualify the symbolic name of whatever is on the right of the operation.

other operators can be introduced as well, such as + for union and ! for complement.

the associativity and precedence of these operators has to be played around with, but intersection should always be lower in order to fit into the general semantics of uri navigation.

1. retrieve the base symbolic name of the resource
2. retrieve the set operation
3. if the resource's name is unique should we short-circuit even if the set described in the path isn't valid? (probably not)

URI Navigation as a Path Through a Directed Graph

start anywhere in the graph

URI Navigation as a Set Operation

there is the set of resources and the set of sets of resources

everything from the first to the last slash of the uri path is treated as a single set operation

uri paths that end with a slash