Re: Editorial changes to clarify usage of URIs / Absolute URIs and @profile

Ivan Herman wrote:
> The bottom line is: I am not convinced all this is necessary, except for some informative warning. I do not think there is any reason to disallow a profile URI of the form http://a.b.c/e#f. This is a perfectly correct URI that can be used for a HTTP GET. So why going out of our way to disallow it?

Indeed, a perfectly valid URI, and the frag will be dropped as part of 
the dereferencing process sometime before the GET happens / request is made.

> There is a fact that is simply the consequence of HTTP. If we have two profile URI-s, namely http://a.b.c/e#f and http://a.b.c/e#g, then these two, while returning the same RDF graph serialized in some form when a GET is performed, ie, defining the same prefixes and terms (which is still fine!), may be considered as different for a caching mechanism, ie, it may be less efficient to handle them. This is not error, just an awkwardness for whoever used them....

Yup, every HTTP cache will not use the frag URI that's for sure, 
will/should be caching HTTP responses relating to requests, and will 
"see" both URIs as 'http://a.b.c/e' - I guess somebody may hard code the 
graph(s) as being associated with the frag URI(s), in which case yeah 
that could be a bit awkward for them and potentially lead to unexpected 
behaviour (say where the hard coded graphs is associated with /e and 
/e#f but not /e#g).

I was just suggesting that we changed the value space of @profile to be 
absolute-URI, because then regardless of whether somebody wrote 
http://a.b.c/e or http://a.b.c/e#f or http://a.b.c/e#g in @profile, it 
would always be seen as http://a.b.c/e .

I'm easy w/ any text though, and even w/ not saying anything, the common 
case is covered and it's only people who'll hard code / cache against 
hash URIs which will potentially have problems.

Best,

Nathan

Received on Tuesday, 8 February 2011 16:35:52 UTC