[whatwg] RDFa Features

James Graham jg307 at cam.ac.uk
Fri Aug 29 01:34:43 PDT 2008

Manu Sporny wrote:
> Tab Atkins Jr. wrote:
>> On Thu, Aug 28, 2008 at 4:42 PM, Kristof Zelechovski
>> <giecrilj at stegny.2a.pl <mailto:giecrilj at stegny.2a.pl>> wrote:
>>     Ian's question was about what happens when it goes down forever, or gets
>>     taken over, intercepted, squatted, spoofed or redirected because of a
>>     malicious DNS.  I should have known better how to ask it.  The
>>     browser cache cannot handle these cases.
>> Consider the question to be asked by me as well.  A host of a popular
>> format forgets to maintain its registration and gets squatted by a
>> malicious person. They pick up another url to host their schema on, but
>> legacy pages are still pointing to the old url and now may have poisoned
>> semantics.  Do we have a recourse?
> The way we deal with this today is by using a Persistent URL (aka: URL
> re-direction service) such as purl.org[1] or xmlns.com[2]. We recommend
> that all authors use such a service for their vocabularies. This is how
> the Media, Audio, Video and Commerce RDF vocabularies are hosted.
Given the problems with using DNS as your registry noted above and the 
fact that the recommended solution to this problem is to use a small 
number of registries built atop DNS that promise greater longevity than 
DNS registrations can ensure, it doesn't seem unreasonable to have a 
single permanent registry that provides (at least for HTML 5) a 
canonical prefix:url mapping. So instead of the use of cc:foo requiring 
a deceleration of cc elsewhere in the document, cc would be declared at, 
say, cc.rdfa.net and would be a globally unique prefix from the point of 
view of the author. People not wanting to bother registering would just 
have to use full URLs everywhere. This would seem to provide the "follow 
your nose" principle you desire, remove several of the objections to 
URL-based namespaces, make authoring for the common case of well known 
vocabularies easier, and have only mildly different distributedness 
characteristics to the current recommended practice.

More information about the whatwg mailing list