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

So.... sorry, I misunderstood and misinterpreted some facts, which is not your fault but mine. I should have been more careful... Apologies.

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?

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

Ivan


On Feb 8, 2011, at 16:14 , Nathan wrote:

> Ivan Herman wrote:
>> On Feb 8, 2011, at 12:23 , Nathan wrote:
>>> Ivan Herman wrote:
>>>> On Feb 8, 2011, at 12:12 , Nathan wrote:
>>>>> Hi Shane,
>>>>> 
>>>>> Following on from two discussions on the list about the use of @profiles, and confusion over the terminology "TERMorCURIEorAbsURI" in the current RDFa-Core draft, I'd propose the following clarifications to the spec.
>>>>> 
>>>>> define:
>>>>> 
>>>>> URI
>>>>>  URI  = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>>>>>  A URI conforming to the Generic URI Syntax, as per section 3 of
>>>>>  RFC3986 [1]
>>>>> 
>>>>> AbsoluteURI
>>>>>  absolute-URI  = scheme ":" hier-part [ "?" query ]
>>>>>  An absolute-URI as per section 4.3 of RFC 3986 [2]
>>>> Wait, I am not sure I understand this.
>>>> I do _not_ think that it is worthwhile for us to restrict a @profile value to be an AbsoluteURI in this sense. What you do is to remove the optional fragment, and I think that this is unnecessary on the specification level. We can add some warning on the effect of cache, but that is it.
>>>> What I want to be sure of is that I could not do something like
>>>> @profile="#me"
>>>> ie, a 'pure' fragment ID, ie, a relative URI. (The same, probably, for @vocab.) But the URI specification you quote in the document seems to exclude that anyway. Ie, the spec is probably fine as far as I am concerned, it is just that some explanation might be worth somewhere that we do not use relative URI-s.
>>> what about @profile="../foo" (and likewise vocab) ?
>>> 
>> Hm. Yeah:-)
> 
> Cool, I'd suggest we may just want to focus on value space rather than lexical form then, @profile with a value space of AbsoluteURI, and everything else with a value space of URI, as currently indicated by the docs. Some text for @profile which says something like:
> 
>  profile
>  a white space separated list of one or more URIs that indicate a profile of terms, prefix mappings, and/or default vocabulary declarations. Note that the value space of @profile is AbsoluteURI and consequently any fragment identifier will be ignored. See RDFa Profiles;
> 
> ?
> 
> 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