Re: fragment identifiers

Roy T. Fielding wrote:

>
> The part that RDF has wrong is the notion that a fragment identifier
> is necessary to denote resources that are not documents.  That position
> is neither supported by Web architecture nor supported by historical
> use of anchors, nor does it make any logical sense to me as an implementor
> of HTTP clients and servers.
>

This is TimBL's argument, but it is not something _required_ by RDF, that is
RDF mostly treats URIrefs as opaque names. Well at least that's the case as
far as the RDF model theory is concerned. The issues with RDF + URI/refs
have to do with what happens between the RDF/XML that is in some document
and the resulting collection of triples that the model theory deals with.

Tim has said otherwise, that URI references ought not be treated as opaque,
rather that their _range_ depends on the scheme and other syntax such as
whether a fragment id is present or not. But RDF has no way to make use of
this information because RDF _itself_ has no mechanism to parse URI
references. One can only make assertions about URIreferences and within RDF
one can draw no conclusions based on the syntax of the URI reference. Tim
says that "http" URIs ought only refer to _documents_ which makes some
intuitive sense, but I've yet to hear a purely logical or pragmatic reason
why this must be the case -- e.g. what breaks if we allow something like
http://example.org/term/Car to refer to the concept "Car"? RDF would be
happy as a clam with this.


Jonathan

Received on Tuesday, 23 July 2002 21:50:19 UTC