Re: PURLs don't matter, at least in the LOD world

On 17/02/12 21:08, Kingsley Idehen wrote:
> On 2/17/12 2:18 PM, David Booth wrote:
>> On Fri, 2012-02-17 at 18:48 +0000, Hugh Glaser wrote:
>> [ . . . ]
>>> What happens if I have http://purl.org/dbpedia/Tokyo, which is set to
>>> go to http://dbpedia.org/resource/Tokyo?
>>> I have (a), (b) and (c) as before.
>>> Now if dbpedia.org goes Phut!, we are in exactly the same situation -
>>> (b) gets lost.
>> No, the idea is that the administrator for http://purl.org/dbpedia/
>> updates the redirect, to point to whatever new site is hosting the
>> dbpedia data, so the http://purl.org/dbpedia/Tokyo still works.
>>
>>
>>
> David,
>
> But any admin that oversees a DNS server can do the same thing. What's
> special about purl in this context?

Precisely that they don't require an admin with power over the DNS 
registration :)

To me the PURL design pattern is about delegation authority and it's an 
important pattern.

Two specific use cases at different extremes:

(1) An individual is creating a small vocabulary that they would like to 
see used widely but don't have a nice brand-neutral stable domain of 
their own they can use for the purpose. This one has already been 
covered in the discussion.

(2) I'm a big organization, say the UK Government. I want to use a 
particular domain (well a set of subdomains) for publishing my data, say 
*.data.gov.uk. The domain choice is important - it has credibility and 
promises long term stability.  Yet I want to decentralize the 
publication itself, I want different departments and agencies to publish 
data and identifiers within the subdomains. The subdomains are supposed 
to be organization-neural yet the people doing the publication will be 
based in specific organizations. The PURL design pattern (though not 
necessarily the specific PURL implementation) is an excellent way to 
manage the delegation that makes that possible.

So my summary answer to Hugh is - they are much more important to the 
publisher than to the consumer.

Dave

Received on Saturday, 18 February 2012 12:58:19 UTC