- From: Stefano Mazzocchi <stefano@apache.org>
- Date: Thu, 18 Nov 2004 10:35:00 -0800
- To: Jeen Broekstra <jeen@aduna.biz>
- CC: Patrick.Stickler@nokia.com, A.J.Miles@rl.ac.uk, www-rdf-interest@w3.org, public-esw-thes@w3.org
Jeen Broekstra wrote: > > Patrick.Stickler@nokia.com wrote: > > [snip] > >>> (2) If you do think it's worth adding something to SKOS Core, what's the >>> best idea for a local name? >> >> >> >> Anything without a fragment identifier ;-) > > > I realize I'm probably opening up a can of worms of the 'Holy War' brand > here, but what exactly is the problem with using fragment identifiers? > It seems to me that this is more a matter of esthetics/taste than > anything else, there doesn't seem to be much of a technical difference > between the two. > > If this has been discussed to death before, please feel free to tell me > so and/or provide a pointer to such a discussion. There is a difference. Dereferencing http://blah.com/foo#bar will send "foo" to the server, and keep "bar" on the client. Dereferencing http://blah.com/foo/bar will send both "foo" and "bar" to the server. For some people, the second is a reason to avoid the first because it makes it harder to dereference single concepts. For others, the second is to avoid because it's an implementation-driven compromise (and, in fact, might go away with a Sparql web service) and has the side effect of not allowing you to separate "foo" from "bar" if not positionally and might yield to hierarchies of concepts that is against the concept of a flat URI space. I personally think that once Sparql web services are available, the # vs. / debate will very likely disappear, because at that point, you can dereference a single URI, even if it uses a # -- Stefano.
Received on Thursday, 18 November 2004 18:34:57 UTC