[URI vs. URIViews] draft-frags-borden-00.txt

Apropos the discussion of URI vs. URIviews:

Clearly the RDF community intends to identify <rdf:resource>s by URI
references.

On the other hand RFC 2396 identifies <rfc2396:resource>s by URIs. The
status of what a fragment identifier identifies is a bit unclear from the
documents and practice. We have submitted an internet draft which attempts
to clarify this.

http://www.ietf.org/internet-drafts/draft-borden-frag-00.txt

This is an early draft, and needs to be cleaned up a bit but is presented
for discussion.

To summarize:

On the HTML/HTTP web, a URI reference is resolved to a fragment of a
document by the following process:

1. URI part sent to HTTP server
2. HTTP server maps _resource_ identified by URI onto document
representation which is called an _entity_
3. Entity returned to client.
4. Client parses entity, and uses fragment identifier to obtain piece of
document for display.

In this usage, which is straightforward, a given fragment identifer e.g.
#toc is interpreted according to the rules of the returned media type
text/html directing the browser to display the table of contents.

RDF, however, uses URIreferences as opaque identifiers for resources and
this identification is outside any HTTP transaction -- hence no media type
applies. The issue is that without a media type, there is nothing to define
the syntax of a fragment identifier, or what it might identify.

See:
http://www.ietf.org/internet-drafts/draft-borden-frag-00.txt

A generic fragment identifier syntax is defined which encapsulates known
fragment identifier syntaxes:

The term "sub resource" is introduced, to define what a URI reference
identifies. The relationship between a URI reference and a "sub resource" is
the same as the relationship between a URI and a "resource

rdf:resource is the union of rfc2396:resource and draft-frags:subresource

This is intended to reflect common usage in the RDF community as well as XML
Namespaces whose names are also URI references.

Jonathan