- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 17 Feb 2004 14:11:26 +0200
- To: "ext Ron Daniel" <rdaniel@taxonomystrategies.com>
- Cc: <www-rdf-interest@w3.org>, "'DuCharme, Bob (LNG-CHO)'" <bob.ducharme@lexisnexis.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