Hi Hugh,
I can only speak for one case, some PURLs I have maintained for the last 5 years - the Personally Identifiable Information Namespace http://purl.org/pii/terms/# There are 16 terms. The use for the terms is in discovery, as a penultimate node to rdf:nil in Lists and Collections. Imagine you have searched a dataset repository catalog for Assets (e.g. ADMS). The list is finite, but the subject you were searching for is not. The "end" of the list is not rdf:nil, it is a subject token PII Term. rdf:nil has the meaning that you have searched the entire universe. Public Social Networks and Repositories may not contain search able PII, but as businesses they all have customer lists which can and do contain PII - but you are not able to search those. The point is often blurred, because search engines return thousands of links. --Gannon ________________________________ From: Hugh Glaser <[email protected]> To: "[email protected]" <[email protected]> Sent: Friday, February 17, 2012 12:48 PM Subject: PURLs don't matter, at least in the LOD world (Sorry if there is a paper/discussion on this that I have missed somewhere. And I may have some of this wrong, as I have essentially not used PURLs.) M Scott Marshall and others' comments have prompted me to put pen to paper and ask what the list thinks on this. It has long puzzled me why people seem to think that PURLs (and Handles, etc.) solve some actual problem. Leaving aside the question of whether it actually adds extra fragility as to whether purl.org will continue to exist. (Personally I would bet the Library of Congress will last longer than purl.org, but I would have to wait too long to collect on the bet to make it worthwhile.) In the Linked Data world, at least, what does a PURL give protection from? Let's say I have http://dbpedia.org/resource/Tokyo. I can: a) Use the URI without any URI resolution at all, and it is really useful to do so (as commented, foaf:name is used a lot, and it does not depend on anything being at the other end to resolve to); b) I can resolve to find out what DBPedia thinks it "means" (returns as RDF); c) I can use it as an ID for another source to find out what that other source thinks it "means". Now let's say dbpedia.org goes Phut! What I lose is facility (b) 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. Both of these situation can be fixed by persuading someone (the registrar for dbpedia.org or the purl.org organisers respectively) to allow someone else to take over purl.org/dbpedia or dbpedia.org respectively. But once dbpedia.org goes Phut!, you get a dead link whatever you do, until someone takes it over. Not much to be gained for the overheads of having the purl? I can see that in the Web of Text, a URI that has gone 404 is rather painful. And I know that people who have curated data find dying links painful, and seem to find Handles etc some sort of comfort for their concerns, even though they don't necessarily solve the perceived problem, in my view. But in the Web of Data, given a good guess at somewhere else (such as the LoC, or even the Virtuoso endpoint or sameAs.org), I stand a good chance of finding a skos:*Match or even an owl:sameAs that will get me back on track again. Is there something I am missing about PURLs? Best Hugh -- 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/
