mistakenly tombstoned PURL

[Melanie Courtot]

Hi,

Could you untombstone the PURL /obo/oae/about/?

I send a note via the form at http://www.oclc.org/research/forms/feedback-form.html (with subject "PURL") last week, but haven't heard back, so I am unsure if it reached someone.

Thanks,
Melanie


---
Mélanie Courtot
MSFHR/PCIRN Ph.D. Candidate,
BCCRC - Terry Fox Laboratory - 12th floor
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada

[Young,Jeff (OR)]

Melanie,

Sorry about that. I initiated a database update request, but it appears to have fallen through the cracks. I'll ping them again.

The feedback form was the appropriate mechanism for the purl.org server, but requests to untombstone have some red-tape involved and are not treated as a priority.

Apologies to the persistenturls group, which is mainly concerned with the open-source software rather than the purl.org installation. Perhaps I could make up to everyone by recommending 410 (Gone) rather than deleting/tombstoning regardless of the installation.

Jeff

[Christian Chiarcos]

Dear all,

I have a problem related to mistakenly tomstoned PURLs: I wanted to replace a bunch of individual PURLs for different resources (http://purl.org/olia/olia.owl, .../system.owl, etc.) by a single PURL (http://purl.org/olia) with partial redirect. In this way, any subsequent updates would have been a lot easier.

Of course, the individual purls overrode the partial redirect, so I thought tombstoning them might be a good idea. It turned out not to be ... and it turned out to be irreversible ...

So, I was wondering if this behavior, preferring tombstoned purls over partial redirects (where both are applicable) is intended, and if so, I would suggest to document it somewhere more prominently. If not, however, this would be software-related request ;) Another idea of course, would be to provide some interface for untombstoning PURLs.

Thanks a lot,
Christian

BTW: I used the feedback form already and described the problem, asking to untombstone the individual purls (as deletion is not possible).

[David Wood]

Hi Christian,

Tombstoning of PURLs was a design requirement.  It has caused a lot of confusion.  In fact, I think it is possible that the majority of the traffic on this list over the past few years relates to un-tombstonging requests to the OCLC administrator (currently Jeff Young) instead of being related to the software itself.

The rationale for tombstoning is /persistence/.  PURLs should not be treated as just another URL.  They should be persistent.  Therefore (so went the requirement), tombstoning is preferred over deletion.

So, I'm afraid that you will need to make your deletion requests to Jeff for purl.org PURLs that get in your way.  Sorry!

Regards,
Dave
--

http://about.me/david_wood

--
You received this message because you are subscribed to the Google Groups "persistenturls" group.
To unsubscribe from this group and stop receiving emails from it, send an email to persistenturl...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Peter Ansell]

Hi David,

Is the software being maintained still? The Google code repository looks to be fairly dormant for the past two years.

I don't mind looking into a patch to either partially or fully revert this design requirement given its consequences for both innocent users and experienced administrators. It is a little alarming that the requirements document led to a system where tombstoning (under the name "delete") is an irreversible action from the user and administrator web interfaces and requires a manual database query to fix. Hopefully it would not be difficult to patch as long as the stakeholders agree it is advantageous to everyone to allow fixes from the web interface.

I accidentally deleted a PURL at purl.org today and it is stuck in the tombstone state. What is particularly strange in my case is that I was experimenting with a sub-path and when I deleted it, the top domain still works, except for the tombstoned subpath. I naively expected that the subpath would simply disappear with deletion based on experience with all other applications I have worked with, with the top domain reinstated as the rule for those PURLs, as they definitely still exist. I can understand if a top level domain was tombstoned that it would be 410'd, but I don't understand the rationale for defaulting to tombstone a subpath when the domain still exists. More than anything, it seems to go against the idea of persistence to have a system which kills links so effectively and quickly.

Top domain is: purl.org/podd/ while the experimental sub-domain which is now stuck in the tombstoned state is: purl.org/podd/ns/. I haven't yet sent a request using the feedback form that other users refer to in this forum as I am not sure what the URL for the form is.

Jeff mentioned that this forum/group is supposed to be for supporting the software itself, which is part of my mixed query. Is there a forum for discussing the purl.org service itself?

Cheers,

Peter

[Young,Jeff (OR)]

Peter,

I will initiate the database request to recover your PURL. It may take a few days to process. 

There isn't a real forum for discussing the purl.org instance specifically, but I've copied da...@oclc.org who may want to consider this.

Jeff

Sent from my iPad