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

Many thanks Scott.
I hope you realised that I didn't want to imply you were describing any particular scenario with respect to PURL - it was more your comments sparked something off for me.
And thank you for your late-night efforts to describe the SharedNames scenario!
It is very helpful; I had tried to get my head round it from the site, you give quite a lot more of the motivation.
Of course, all this sort of stuff interests me, as I have my own way of doing these or at least strongly related things (sameas.org, which happens itself to only have Linked Data URIs, but other sameas.org sub-sites have arbitrary identifiers).
I think the important thing is that the solutions need to be situated in the application context - a strong societal motivation should be ridden hard to get the benefit from it, and that seems what is happening in this case.
I would need to spend quite a long time trying to follow the concerns and why the proposed solution helps better than any other, but late on a Friday I won't try that. :-)
Thanks again.
Hugh

On 17 Feb 2012, at 22:59, M. Scott Marshall wrote:

> 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

-- 
Hugh Glaser,  
             Web and Internet Science
             Electronics and Computer Science,
             University of Southampton,
             Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

Received on Friday, 17 February 2012 23:18:52 UTC