RE: pound sign vs. slash as final URI delimiter

Your point is significant, and insofar as RFC2396 is concerned, inability
to reliably interact with a server per a URIref with fragid is to be expected.

The bottom line, for me at least, is this:

If your resource is important (and IMO all vocabulary terms are important)
then it should be possible to GET representations of those resources. If
one is to reliably GET representations of resources, they should not be
denoted by URIrefs with fragids.

URIrefs with fragids are "second class identifiers" on the web. If you
don't want to treat your resources as second class resources, then just 
don't use them.

Any relationships between a term and vocabularies/ontologies it belongs to, 
models in which it is employed, stylesheets which adjust presentation
per those terms, etc. can (ideally) be defined in RDF and discovered by simply 
requesting an authoritative description of the term, from which the identity
of those other resources and their relationships can be obtained. Using
a fragid with base URI to capture relations between terms and vocabularies
is unnecessary and leads to numerous practical problems.

Just say no to "#".

Regards,

Patrick



-----Original Message-----
From:	www-rdf-interest-request@w3.org on behalf of ext Eric Jain
Sent:	Tue 2004-02-17 17:18
To:	rdf-interest
Cc:	
Subject:	Re: pound sign vs. slash as final URI delimiter



> <http://example.com/foo#bar> can denote an entirely
> different resource than <http://example.com/foo>

From http://www.ietf.org/rfc/rfc2396.txt: "[...] the optional fragment
identifier, separated from the URI by a crosshatch ("#") character,
consists of additional reference information *to be interpreted by the
user agent* after the retrieval action has been successfully completed."
(emphasis mine).

This would seem to imply that user agents have no obligation of passing
on fragment identifiers, and servers no business of making use of them.
On the other hand this does of course not imply that there isn't a lot
of existing software that assumes otherwise...

Yet another option may be to use URNs as resource identifiers, e.g.
rdf:about="urn:test:123". One question in this context: Is it correct to
say that the previously mentioned resource is '123' in the 'urn:test:'
(or 'urn:test'?) namespace?

Received on Wednesday, 18 February 2004 07:29:56 UTC