<div dir="ltr">Hello Dorothea,<br><br>another excellent topic.<br><br>Because the question is so broad, I'd like to narrow my response down to two areas: good repository functionality and good software.<br><br>Although the areas I describe might have some low-baseline definition of what's good or bad, it's often a case of "what's good enough, to reach the intended purpose of the system". Stated differently "What's good enough to address the needs and requiremens of my institution".<br>
<br>1. Good Repository Functionality<br><br>1.1 Flexibility to "properly" ingest and support all the types of data and information that the system claims it can ingest and support.<br><br>If the system claims it can ingest any bitstream, together with a series of descriptive metadata fields, it should be really able to do so. However, this might not be the detailed definition of "properly" that your institution has in mind. <br>
<br>For example:<br><br>* If there is a need to ingest and properly support an item, and keep the relation between that item and it's different versions, additional functionality is required.<br><br>* Special collections often have a need for special purpose functionality: "properly" ingesting video files and supporting them, might mean they should be converted on ingest and being streamed instead of downloaded when someone clicks the files.<br>
<br>A good general purpose repository can be configured or customized in order to get as close to this required definition of "properly". <br>It should state which kinds of special purpose functionality it supports. An open interface should be available for institutions or third parties to create additional special purpose functionality for ingesting and properly supporting special formats.<br>
<br>1.2 Future-proof: ensuring that all stored data or information can be migrated or exported in a lossless way.<br><br>Although many (database) systems claim that they can stand time, the average lifespan of information storage systems are still around 10 years. A good repository platform offers functionality to both migrate metadata and bitstreams, to newer formats, or has at least an open API that allows you to plug other migration or export software.<br>
<br>2. Good Software<br><br>2.1 Continuity: Active community, open source, reliable vendors<br><br>Good software doesn't imply that it is free of defects or bugs. That's why continuous improvement is a hard requirement when you decide to integrate a repository platform as a strategic system within your institution. A lively community of developers and users is a good base to start from, whether commercial or open source: if the software is widely used or sold, it demonstrates that support will probably be around for a while. <br>
<br>If the code of the system is open source, your institution can always modify the code itself, if no other help is available. Nowadays, commercial vendors often have escrow agreements that offer clients the code as well, once the company ceases to exist or stops offering support for certain products.<br>
<br>In either case, if you want to assess continuity: the number of developpers, number of deployed installations, release cycle history or the future release roadmap are good indicators to look at.<br><br>2.2 Scalability<br>
<br>The software should make a clear statement what magnitudes of users, stored objects, ... can be handled. If this is a fuzzy area, a range of examples should be available to demonstrate which combinations of the software, and server configurations work to serve a certain load, and which don't.<br>
<br>It would be great if you could state this requirement as "the system should support an infinite number of users, and an infinite amount of stored data", but I'm afraid that's a bit far-fetched for any system.<br>
<br>2.3 Compatibility<br><br>If the software heavily relies on other software components (java, apache, databases, ...), the software should be compatible with recent versions of these components, mainly for performance and security reasons. If there is no such compatibility yet, someone should be able to estimate when it will be.<br>
<br>2.4 Usability<br><br>Good software should be user friendly. It's difficult to make sure that all types of users will be able to figure out in a short time-span how they can do the actions they want. I think a baseline for usability is the presence of meaningful error messages for administrators. The person who achieved to install and run the repository, should first of all receive an error message when something goes wrong. Based on that error message, a community or other third party should be able to help this person.<br>
<br>Concerning usability of interfaces: I believe there's nothing wrong with having an "administrator" or "expert user" interface, where you can actually damage the system infrastructure through wrong usage ... But every one of these administrator interfaces should be properly documented.<br>
<br>with kindest regards,<br><br>Bram Luyten<br><br>-- <br>@mire NV<br>Romeinse Straat 18<br>3001 Heverlee<br>Belgium<br>+32 2 888 29 56<br><br><a href="http://www.atmire.com">http://www.atmire.com</a> - Institutional Repository Solutions<br>
<a href="http://www.togather.eu">http://www.togather.eu</a> - Before getting together, get Tog@ther<br><br><div class="gmail_quote">On Tue, Sep 2, 2008 at 12:04 AM, Dorothea Salo <span dir="ltr"><<a href="mailto:dsalo@library.wisc.edu">dsalo@library.wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sorry, all, I was on holiday and didn't think to set up this week's<br>
question in advance. (Also, since the statistics discussion is still<br>
ongoing, I'm waiting to summarize to the wiki until talk dies down. By<br>
all means keep talking!)<br>
<br>
This week's question sounds simple but isn't. What is good repository<br>
software? What does it allow us to do (both macro- and micro-level)?<br>
What do we accomplish with it?<br>
<br>
I'm going to ask that respondents please write their own answers<br>
before reading those of others! I would like to see some diversity of<br>
response. Feel free to respond directly to me if you feel<br>
uncomfortable answering on the list.<br>
<br>
I will moderate a chat on this topic in the DSpace IRC room (#dspace<br>
on <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>) on Wednesday at 10 am Central, 11 Eastern, 4 pm<br>
GMT.<br>
<br>
Have at it!<br>
<br>
Dorothea<br>
<br>
--<br>
Dorothea Salo <a href="mailto:dsalo@library.wisc.edu">dsalo@library.wisc.edu</a><br>
Digital Repository Librarian AIM: mindsatuw<br>
University of Wisconsin<br>
Rm 218, Memorial Library<br>
(608) 262-5493<br>
<br>
-------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<br>
Build the coolest Linux based applications with Moblin SDK & win great prizes<br>
Grand prize is a trip for two to an Open Source event anywhere in the world<br>
<a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>
_______________________________________________<br>
DSpace-tech mailing list<br>
<a href="mailto:DSpace-tech@lists.sourceforge.net">DSpace-tech@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/dspace-tech" target="_blank">https://lists.sourceforge.net/lists/listinfo/dspace-tech</a><br>
</blockquote></div><br><br clear="all"> <br>
</div>