Re: pound sign vs. slash as final URI delimiter

Patrick Stickler wrote:
> 
> I strongly advise avoiding the use of fragment identifiers.
> 
> See further comments/arguments below...
...
> 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>.
> 

I think that the whole concept of using fragids would work fairly well 
if you adopt this picture -

1) The resource to be retrieved will be an HTML document explaining the 
terms in human-readable form.

2) That resource contains entries for each (or at least most) fragid in use.

Under these conditions, a browser will present the definition you want, 
you will be able to scroll around and search for other nearby terms 
(with the same base uri), and usability will be good.

Without fragids, someone would have to create a separate resource for 
each uri reference, and a user retrieving one could not look around to 
easily find information on similar fragids but would instead have to 
load other resources.

With this picture, fragids are actually highly preferable, as it reduce 
s the load on the server (and the people at that end), and the number of 
reesources that have to be created and maintained, and makes life better 
for the user.

Does the picture change if the base uri returns an rdf document instead? 
  Here we get into the lack of standards for what such a resource should 
contain and how to get it.  There is also the question of what the 
purpose is.  The two likely purposes are not completely congruent.

a) A person needs to read a definition so as to know how to write 
software and interpret an rdf data set.

b) A processor needs to look up a term to know what constraints to levy 
on a particular resource (and possibly to know what label to display).

a) is well-suited by the html picture, b) is not.  Both are legitimate 
needs.

> 
> 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. 

Using a slash instead of a hash has no bearing on this - evenwith a 
slash there is no guarantee that any of those good things will occur.

> 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.
> 

Likewise the same for slash as for hash.

> 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.
> 

It could for case a), but case b) would be questionable.  URIQA could go 
part of the way, but some convention or standard is needed to cover the 
rest.


I used to regard the use of hashes for these purposes with disdain and 
suspicion, but in  view of the advantages for case a) I find I have 
moderated my position.  Better, I think, would be to devise a way 
whereby the hash could also be made to work well when the material to be 
returned is in rdf.  Then both case a) and b) would work well with the 
hash.  I think that any solution should bear in mind that case a) is 
sometimes what is wanted, and not to throw it out.

Cheers,

Tom P

Received on Tuesday, 17 February 2004 08:36:34 UTC