W3C home > Mailing lists > Public > public-lod@w3.org > February 2012

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

From: M. Scott Marshall <mscottmarshall@gmail.com>
Date: Fri, 17 Feb 2012 23:59:09 +0100
Message-ID: <CACHzV2PFwJsashCJjB160aS6Y2OAF3tNGsGe6xKV9io-fJtdtA@mail.gmail.com>
To: Hugh Glaser <hg@ecs.soton.ac.uk>
Cc: David Booth <david@dbooth.org>, "public-lod@w3.org" <public-lod@w3.org>
On Fri, Feb 17, 2012 at 8:51 PM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote:
>
> On 17 Feb 2012, at 19:18, 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.
> Thanks David.
> But someone has to persuade the administrator to do that.
> If the owner of http://purl.org/dbpedia/ and dbpedia.org is co-operative, then all is good.
> But then it is a similar challenge to provide a redirect at dbpedia.org or re-assign the dbpedia.org domain, so not much gain there.
> And this is the situation that big organisations will usually be in, in relation to their own URIs.
> If the owner is not co-operative, then I am guessing (sorry, I can't find it in the documentation) that it is quite a challenge to get the administrator to re-assign a PURL domain to someone else.
> But of course it is quite a challenge to get a domain registrar to move a domain registration - I am sure it is actually harder, so some gain.

Hugh - you are responding to a scenario that I wasn't proposing. Mea
culpa. I'm afraid that I never stated the use of PURLs that I had in
mind. Let me try to briefly explain the motivation of SharedNames,
keeping in mind that it's late on a Friday night here in NL and
SharedNames was established in 2008 by a number of people. See
http://sharedname.org/ for more info. Oh dear. Don't know if I'm up
for explaining SharedNames in a nutshell. Ok, here goes..

SharedNames is based on the notion of federated PURL servers under
control of the URI owners.

Once upon a time..
In the land of Bio-identifiers, there are many valuable database
resources (see the annual survey of Nucleic Acids Research where they
count >1800) and LOD-savvy bio(medical)informatics practitioners want
to refer unambiguously to the information records with URIs-
preferably using the same identifiers for common types of records
about genes, proteins, compounds, etc. to save a load of
mapping/translation.

We faced a few problems:

1) Key database maintainers were not aware of the wonders of linked
data. That would explain why you wouldn't want to wait to see what
kind of URI policies came out of institutions with varying levels of
W3C expertise and motivations.

2) URIs were consistently being used as advertisements or name
branding (and still are unfortunately - in some cases politicising
data ! but that's another story). Understandably so. However, it is
also understandable when things change drastically that the domain
owner has other priorities than keeping your identifiers valid.

Strategy:
>From http://sharedname.org/page/Project_overview:
"Control of shared URIs should be in the hands of those who depend on
them. This is the best way to ensure that the URIs serve the community
in the ways listed above."

With few exceptions, biodata providers have not had the resources to
create either RDF renderings or URIs for their data. We want
well-formed and well-behaved URIs and we want them now. So, we
suggested creating a vendor-neutral namespace of URIs backed up by a
federation of people/organizations/servers.

So, we set out to create a *federation* of organizations with
governance for a *federation* of PURL servers. In such a federation,
if any member stepped out or a server failed, it wouldn't disable the
other servers and the organization would continue. Federated PURLz
software would be required so we set about outlining the requirements
and contracted the software. The software is in beta testing although
I don't know if it is actively being tested now.

> But overall, I still can't really see the effort is worth the candle, certainly for big organisations that have expectation of longevity.

I hope that LOC is the epitome of longevity but we've all seen very
large organisations and institutions and even countries both change
their names and ownership, as well as disappear from all levels of
society. Would examples help? Sun swallowed by Oracle. Genentech
swallowed by Roche. There are many corporate examples as well as
governmental examples. Some example changes from the bio domain:
Locuslink to Entrez Gene, Swissprot to Uniprot, ..

-Scott
Received on Friday, 17 February 2012 22:59:40 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:37 UTC