W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2011

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

From: Ivan Herman <ivan@w3.org>
Date: Tue, 8 Feb 2011 17:50:37 +0100
Cc: Shane McCarron <shane@aptest.com>, RDFA Working Group <public-rdfa-wg@w3.org>
Message-Id: <2358430F-11E9-43D5-AA59-992CF4396BA2@w3.org>
To: nathan@webr3.org

On Feb 8, 2011, at 17:34 , Nathan wrote:

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

If we do that than an implementation may have the obligation to check, the URI may be defined as not comformant, we would have the obligation to decide what happens if that is the case (would we block processing for the whole subtree?), re-edit the document, etc., etc.,... I just do not feel all this is worth the trouble!


> 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

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Tuesday, 8 February 2011 16:50:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:24 UTC