W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

Re: pound sign vs. slash as final URI delimiter

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 17 Feb 2004 14:11:26 +0200
Message-Id: <68BD6100-6142-11D8-8D4A-000A95EAFCEA@nokia.com>
Cc: <www-rdf-interest@w3.org>, "'DuCharme, Bob (LNG-CHO)'" <bob.ducharme@lexisnexis.com>
To: "ext Ron Daniel" <rdaniel@taxonomystrategies.com>


I strongly advise avoiding the use of fragment identifiers.

See further comments/arguments below...


On Feb 16, 2004, at 18:07, ext Ron Daniel wrote:

>
> Hi Bob,
>
> My current rule of thumb is to use '/' unless there is some good
> reason not to. But this is not a strongly held belief.
>
> Why do I prefer '/' over '#'?
> 1) Fragment IDs imply downloading the source document, then picking 
> through
>    it for the bit you need. For large vocabularies, like many produced 
> by
>    Government agencies, this would be a performance issue.

Exactly. Also, there's no guaruntee that the base document contains
the full authoritative definition of the resource in question, even
if you do download the whole thing (see below).

> (Of course,
>    whether something is actually downloaded just because we have used 
> its
>    URL as a namespace ID is another issue.)

> 2) There are some people who are vociferous in maintaining that there 
> is a
>    very big difference between a resource and a fragment ID, and that 
> RDF is
>    about describing resources. I am not personally sure of this, but 
> don't
> see
>    much harm in using '/'.

One problem with using URIrefs with fragment identifiers is that
alot (even most?) HTTP software agents presume that the fragment
identifier is relevant *exclusively* within the context of
processing/intepreting a representation by some client (and I
actually agree) and so any HTTP requests with URIrefs having
fragment identifiers can become corrupted between the originating
client and the server ultimately responding to the request, such
that the fragment identifier is lost.

So, a request such as

GET http://example.com/foo#bar HTTP/1.1

can end up at the server as

GET http://example.com/foo HTTP/1.1

and since <http://example.com/foo#bar> can denote an entirely
different resource than <http://example.com/foo>, this can result
in misunderstanding between the client and server if the server
is expected to do something in terms of the resource denoted
by <http://example.com/foo#bar> rather than the resource denoted
by <http://example.com/foo>.

For traditional HTTP+HTML usage, this is not a big deal. But for
SW applications this will be a continual source of problems.

C.f. my discussion about this relating to URIQA requests:
http://sw.nokia.com/uriqa/URIQA.html

>
> Why I hesitate to categorically state that '/' should be used instead 
> of
> '#'?
> 1) Because # should fit a lot better with picking a predicate out of an
>    XML document that specifies the namespace.

Yet this illustrates a big source of confusion with URI refs
with fragment identifiers. There is no guaruntee that the base
URI will denote and resolve to an RDF/XML instance, nor is there
any guaruntee that the fragment identifier will occur as the
value of an rdf:ID attribute. Furthermore, even if the fragment
identifier occurs in an rdf:ID attribute, that doesn't mean
that the element bearing that attribute contains the complete
definition of that resource, even in that particular RDF/XML
instance, as there can be other elements with rdf:resource
and the full URI defining additional statements about the
resource.

In short, trying to rely on HTML-like fragment identifier
resolution to obtain authoritative definitions of terms
simply does not work in a sufficiently general and scalable
fashion for arbitrary RDF encoded knowledge.


>
> I'd appreciate it if people could clarify things.

So would I. Despite liking the majority of the TAG's
web architecture document a great deal, I didn't find it
to provide a satisfactory treatment of URIrefs with fragment
identifiers, and it's hard to see how the new language of
"secondary resources" really solves practical issues such
as noted above (the discussion about XML namespaces was particular
disappointing). C.f my comments:
http://lists.w3.org/Archives/Public/www-archive/2004Feb/0003.html

Regards,

Patrick


>
> Ron
>
>> -----Original Message-----
>> From: www-rdf-interest-request@w3.org
>> [mailto:www-rdf-interest-request@w3.org] On Behalf Of
>> DuCharme, Bob (LNG-CHO)
>> Sent: Monday, February 16, 2004 7:15 AM
>> To: www-rdf-interest@w3.org
>> Subject: pound sign vs. slash as final URI delimiter
>>
>>
>> This feels like a beginner question, but after a few searches
>> I can't find
>> any discussion of the issue. Let's say I have a namespace
>> identified by the
>> URI http://www.example.com/pathname. To identify the name foo
>> from that
>> namespace, what are the pros and cons of identifying it with a URI of
>> http://www.example.com/pathname/foo as opposed to
>> http://www.example.com/pathname#foo? The pound sign seems to
>> more clearly
>> indicate "the following is a name from the namespace named up to this
>> point," but I see that most references to Dublin Core names (e.g.
>> http://purl.org/dc/elements/1.1/creator) use the slash.
>>
>> Perhaps the question is better framed without reference to
>> syntax: is it
>> better for a name from a namespace to have it's own complete
>> URI or for it
>> to be referenced using a fragment identifier appended to the
>> URI for its
>> namespace?
>>
>> thanks,
>>
>> Bob
>>
>>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Tuesday, 17 February 2004 07:19:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:58 UTC