Hello Dorothea,
another excellent topic.
Because the question is so broad, I'd like to narrow my response down to two
areas: good repository functionality and good software.
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".
1. Good Repository Functionality
1.1 Flexibility to "properly" ingest and support all the types of data and
information that the system claims it can ingest and support.
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.
For example:
* 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.
* 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.
A good general purpose repository can be configured or customized in order
to get as close to this required definition of "properly".
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.
1.2 Future-proof: ensuring that all stored data or information can be
migrated or exported in a lossless way.
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.
2. Good Software
2.1 Continuity: Active community, open source, reliable vendors
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.
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.
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.
2.2 Scalability
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.
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.
2.3 Compatibility
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.
2.4 Usability
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.
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.
with kindest regards,
Bram Luyten
--
@mire NV
Romeinse Straat 18
3001 Heverlee
Belgium
+32 2 888 29 56
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get [EMAIL PROTECTED]
On Tue, Sep 2, 2008 at 12:04 AM, Dorothea Salo <[EMAIL PROTECTED]>wrote:
> Sorry, all, I was on holiday and didn't think to set up this week's
> question in advance. (Also, since the statistics discussion is still
> ongoing, I'm waiting to summarize to the wiki until talk dies down. By
> all means keep talking!)
>
> This week's question sounds simple but isn't. What is good repository
> software? What does it allow us to do (both macro- and micro-level)?
> What do we accomplish with it?
>
> I'm going to ask that respondents please write their own answers
> before reading those of others! I would like to see some diversity of
> response. Feel free to respond directly to me if you feel
> uncomfortable answering on the list.
>
> I will moderate a chat on this topic in the DSpace IRC room (#dspace
> on irc.freenode.net) on Wednesday at 10 am Central, 11 Eastern, 4 pm
> GMT.
>
> Have at it!
>
> Dorothea
>
> --
> Dorothea Salo [EMAIL PROTECTED]
> Digital Repository Librarian AIM: mindsatuw
> University of Wisconsin
> Rm 218, Memorial Library
> (608) 262-5493
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
