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
