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

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 18 Feb 2012 13:54:26 -0500
Message-ID: <4F3FF3E2.8040505@openlinksw.com>
To: public-lod@w3.org
On 2/18/12 7:57 AM, Dave Reynolds 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


Don't publishers need to have admin access en route to exploiting the 
delegation services at purl.org? By this I mean: we are moving from DNS 
admin to purl.org service admin, per account. At some point in the 
Linked Data publishing value chain we always hit the admin level 
privileges matter :-)

Ultimately, I believe this issue is one resolved in the Read-Write Web 
realm where folks control their own data spaces and use those data 
spaces as launchpads for their Linked Data publishing -- ditto Identity 
claims declaration. Thus, instead of depending on a single delegation 
service like purl.org, we end up with a federation of individually 
controlled Linked Data spaces.

I've put out a number of demos that showcase declaration of verifiable 
identity claims via blog posts, tweets, simple html docs etc. These 
identity claims are held in profile documents that are really conduits 
to Linked Data spaces. Each of these spaces is endowed with its own 
proxy/wrapper URI capability which enables the kind of Linked Data graph 
portability that folks ultimately expect of a federated Web.

Anyway, I agree that purl.org serves a purpose (for sure) on the 
publishing side. At the same time, I remain unconvinced about the 
longevity and uniqueness of its value with regards to Linked Data.



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Saturday, 18 February 2012 18:54:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:57 UTC