Re: Decommissioning a linked data site

>But I guess that if we had decided to shut done our server altogether

I mean, shut down our vocabulary server, which handles the queries for data on individual concepts. Which would leave us with just the ability to serve a same answer for the entire "domain"...

Antoine


> Dear Bradley,
>
> The second part of your plan reminds me of my recent question on "moving" a dataset
> http://lists.w3.org/Archives/Public/public-lod/2012Apr/0123.html
>
> The object moved (a thesaurus) is quite the same, as the cause for the "moving": in both cases an official version has arisen to replace a first prototype.
>
> We have tried to create a redirection, using a 301 code. But I guess that if we had decided to shut done our server altogether, we would have opted for the same 410 code as you!
> and maybe we'll do, one day...
>
> Cheers,
>
> Antoine
>
>
>> Back in 2009, as an experiment in working with RDFa and linked data, I created t4gm.info <http://t4gm.info>. It is based solely on US Library of Congress library linked data (specifically, the Thesaurus for Graphical Materials), which at the time I created the site didn't have any equivalently accessible linked data. That has long since been rectified by the LoC. So t4gm.info <http://t4gm.info> is at best redundant and at worst potentially confusing.
>>
>> So what I want to do is shut the site down. But there doesn't seem to be much if any best practice around doing that, especially when the site by virtue of its listing with CKAN is part of the LOD Cloud diagram. What I want to do is 1) delist it from CKAN, and then 2) shut the site down, perhaps replacing it with a simple web service returning a 410 status code per RFC 2616. I assume it will be removed from the LOD cloud diagram when that is next updated from the CKAN data.
>>
>> Anyone have any suggestions beyond that? Also, if anyone from CKAN is reading this, I could also use some guidance on how deletion of records is accomplished through the online interface. - cheers, BPA
>>
>> Bradley P. Allen
>> http://bradleypallen.org
>
>
>

Received on Tuesday, 29 May 2012 20:54:13 UTC