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

Ben,

 

purl.oclc.org is a DNS alias for purl.org and has been since the
beginning. There are several others. These domain names work the same
from an HTTP protocol POV, but if you're using them as identifiers in
RDF don't assume they are interchangeable.

 

Jeff

 

From: Ben O'Steen [mailto:bosteen@gmail.com] 
Sent: Saturday, February 18, 2012 9:19 AM
To: Dave Reynolds
Cc: public-lod@w3.org
Subject: Re: PURLs don't matter, at least in the LOD world

 


A quick related question - does anyone know the status of
"purl.oclc.org" - there was a point in time where the service suggested
that this new hostname was going to be the new proper host for purl.org
urls.

I hope they have abandoned this idea, as one sure way to affect url
longevity is to include a organisational brand in it ;)

Ben

On Feb 18, 2012 1:02 PM, "Dave Reynolds" <dave.e.reynolds@gmail.com>
wrote:

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