As I have previously blogged, our community’s attempts to share knowledge and experience of digital preservation tools has been a triumph of good-willed enthusiam over coordination and collaboration. Rather than pooling our tool knowledge we have spread it around the web in list after list and registry after registry. The result is not particularly helpful. Finding the right tool for the job, remains a challenge. COPTR (Community Owned digital Preservation Tool Registry) is an attempt to address this challenge by collating the contents of existing registries and then replacing them with a new community owned registry.
This registry will not belong to any individual organisation, instead it will be owned and supported by the community. It will be wiki based, making it easy for anyone in the community to contribute. And it will provide a feed of data for anyone wanting to exploit the registry information in creative ways.
This effort has the support of the Aligning National Approaches to Digital Preservation initiative and is backed by an initial group of organisations who have agreed to contribute their registry data.
A demonstrator for COPTR has been produced and is available for viewing here. Feedback on this demonstrator, offers of support, or contributions of registry data would be greatly appreciated and should be posted as a comment on this blog, or emailed to “p (dot) r (dot) wheatley (at) leeds (dot) ac (dot) uk” as is appropriate.
Preservation Topics:
Comments
What will make this *the* registry?
Having been burned on GDFR and UDFR, I’m wary of centralized solutions. This XKCD cartoon provides a warning about what usually happens when trying to consolidate standards. Is spreading knowiedge around the Web really a bad thing? It allows more people to contribute than are likely to with any one registry. What could be more useful with less ongoing effort is a well-maintained index of the best tool pages.
Having said that, I’ll add that you’re welcome to use anything you find worthwhile in my own list of software for extracting format information .
Submitted by Gary McGath on 29 May 2013 – 2:41pm Permalink
What was the problem with GDFR and UDFR
Hi Gary,
Thanks for adding your thoughts!
Here’s my index of the best tool pages. In my opinion, most of them aren’t very good. There is loads of duplication between them. Some have very little detail. Most are really out of date. Few provide any useful interface for quickly browsing to what you’re interested in. Trawling that lot for a useful tool would take a long time. This isn’t a criticism of those that have helpfully shared what they know about tools. But it does suggest that individually we don’t have the necessary effort to build a good tool registry. If we worked together, I’m confident that the situation would be different.
What was the problem with UDFR and GDFR? Wasn’t it an ease of use thing, rather than the issue of centralisation? Lots of people contributed to Just Solve…
Clearly just creating yet another registry won’t solve the problem, as you illustrate with the standards diagram. That’s why we want organisations to do this, and already have some initial committers signed up to do just that.
Cheers
Paul
Submitted by Paul Wheatley on 29 May 2013 – 2:58pm Permalink
Great list
And I forgot to say thanks for pointing me to your tool list! I’ve added it to my meta tool list….
Submitted by Paul Wheatley on 29 May 2013 – 3:19pm Permalink
Just Solve It: Software
Hi Paul,
I’ll provide some positive and hopefully constructive feedback in a different thread as I think of it but the first real question that comes to mind reading these two responses, however, is what about Just Solve It? – Isn’t there already a lot of the work in that Wiki to turn it into a tool registry as well?
Just Solve It: Software
Ross
Submitted by Ross Spencer on 29 May 2013 – 11:17pm Permalink
Just solved?
Hi Ross,
Just Solve is certainly the closest I’ve seen to what I think we need, but would need to go quite a bit further as it’s pretty rudimentary at the moment. Thanks very much for the feedback offer!
Paul
Submitted by Paul Wheatley on 30 May 2013 – 10:43am Permalink
Hosting
What is your idea about hosting COPTR? Although it is owned and supported by the community there must be at least one body hosting it. There is a risk here, if the body is not willing or able to host it anymore, for example due to high traffic bills.
In my opinion the wiki database should be shared in order for community members to synchronise it every so often to their own instance. More ideally the wiki database uses a master-slave method for realtime syncing. That way it should be possible to loadbalance the wiki between different instances.
Submitted by Maurice de Rooij on 30 May 2013 – 6:34am Permalink
Good point
Hi Maurice,
Hosting and longevity are important issues to consider. OPF has offered to host to begin with, and I have offers from other institutions in case we need a “backup”. Sharing a feed of data should help with some of the issues you’ve raised, but yes we could go further and share the wiki database. Something to consider once we’re up and running perhaps…
Paul
Submitted by Paul Wheatley on 30 May 2013 – 10:46am Permalink
Backup hosting
Hi Paul,
Of course I have to handle this through formal routing, but I am sure NANETH would be interested in hosting an instance.
Maurice
Submitted by Maurice de Rooij on 30 May 2013 – 11:22am Permalink
Thanks!
Thanks for the offer Maurice, this is much appreciated!
Submitted by Paul Wheatley on 30 May 2013 – 11:24am Permalink