[Dspace-general] Week 3: Good Repository Software

[Mark H. Wood]

Lots of folks are better positioned than I to describe excellence in
document repository software from the end-user or content-administrator
or organizational-administrator POV, so I'll confine my comments to
the operational and information-architecture POV.

o  Leverages the organization's existing authentication and identity
   systems.  DSpace has been getting better at the former, still shows
   room for improvement in the latter.  (Example:  when registering a
   user authenticated through LDAP, there's no need to store locator
   info. such as a phone number or email address, because we can just
   fetch those from the directory when asked, and if we *do* store
   them then the data become stale over time.)

o  Instrumented for monitoring and maintenance.  This goes beyond
   statistics.  Example: I want to build an application-level backup
   system under DSpace so that we can fan out several dead-storage
   copies of new acquisitions *once* rather than backing up terabytes
   of static files every week forever.  To do that, my gadget needs to
   know when a new item comes in and how to identify it.

o  Configurable without rebuilding.  I think the current setup process
   knows too much about deployment issues.  DSpace is atypically good
   in this respect among the Java app.s I've seen, but I'd like to see
   even better decoupling between build time and runtime.  (I haven't
   yet spent enough time with 1.5 to say how much the situation has
   improved there.)

o  Routine operational procedures should be completely automatable.
   Any operation which requires a sysadmin. to sit at a console and
   click buttons is a manual process.  There should be no manual
   processes required for any repetitive task.  (This isn't speaking
   about content ingestion, which is a creative activity and *should*
   be hands-on.)  DSpace is good here -- I just want to keep it that
   way.

o  User functions exposed programmatically.  The repository should be
   usable by machines, not just humans.  Someone is going to come up
   with a use for our pool of documents which is quite unlike anything
   we've imagined, and he should be able to just use the documents
   and/or metadata without going up to his elbows into DSpace code.

Abstracting a bit, I think a repo. should be well fitted to serve as a
component in the organization's information architecture, not just an
isolated tool.  It should use other components which are useful and
strive to be useful to other components.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080903/ce815f3c/attachment.bin