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

Re: ISSUE-84 (Cool URIs and HTTPRange-14): The W3C TAG has asked us to mention that the use of fragment identifiers can be problematic [LC Comment - RDFa Core 1.1]

From: Ivan Herman <ivan@w3.org>
Date: Tue, 8 Feb 2011 11:31:18 +0100
Cc: RDFa Working Group WG <public-rdfa-wg@w3.org>
Message-Id: <403E4B20-3174-4354-810E-DE42EF9EDC4D@w3.org>
To: nathan@webr3.org
I would agree with this restriction. @profile values should indeed be absolute URI-s, and I have not found any explicit text in the document that says so. I guess this should be added to, eg, section 9.

I would not care too much whether the @profile has a fragment or not, as long as it is clear that the fragments are, essentially, stripped by the HTTP rules.

I would actually add the same restriction to @vocab.

On Feb 8, 2011, at 11:18 , Nathan wrote:

> Ivan Herman wrote:
>> There may be one more additional feature we may want to add to the text, beyond what the TAG might give us: avoid using fragid-s in profile URI-s. That is the only URI that an RDFa processor will dereference, and two different URI-s differing by a fragid only will return the same graph. On the other hand, using two different URI-s for the same graph my make the local caching process inefficient (unless clients would strip the fragid part before caching but I would not expect them to do that...)
> Hmm, should we be clarifying the definition of @profile to accept a whitespace separated list of absolute-URIs (never relative, never with fragment) to avoid /some/ unexpected behaviour?
> * I say some, because people could still use "mailto:bob@example.org", but I figure we shouldn't cater for people who like to do things like that!
> Best,
> Nathan
>>>>> ISSUE-84

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 10:30:46 UTC

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