[Dspace-general] Question one: What's working and what isn't?

[Robin Taylor]

Hi Dorothea,

Thinking out loud about input-forms.xml:- In order to provide different
metadata screens for theses we include the word theses in the collection
names. We look for presence of 'theses' in the collection name before
deciding which input-form to use. In effect we are using the collection name
as a proxy for the type of item. Really it would be better for us to ask the
submitter what type of item they are submitting and use an input-form based
on item type rather than collection name. I am interested to know how people
are currently making use of input-forms.xml.

Cheers, Robin. 


 
 


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-----Original Message-----
From: dspace-general-bounces at mit.edu [mailto:dspace-general-bounces at mit.edu]
On Behalf Of Dorothea Salo
Sent: 18 August 2008 17:56
To: dspace
Subject: Re: [Dspace-general] Question one: What's working and what isn't?

Answering my own question... We're currently running 1.4.1 in production,
and are testing and modding 1.5 for a rollout soon.

> This week's question (based on Q21 from the 2006 survey) is about 
> DSpace's existing functionality. Please offer one to three existing 
> DSpace features that you believe work well in your situation,

I'm very happy with Manakin theming (barring a few minor growls). As a
de-facto consortial repository, being able to theme communities and have the
theme cascade to subcommunities and collections is a major win.

In the "little things make a big difference" category, the checksum checker
makes me happy. Accidentally losing or mangling data is a nightmare; it
would completely demolish the trust my user communities have in the service,
and my own trust in the software. That nightly "all is well" email is a
relief.

The HTML display engine pretty much Just Works. Some of the best and most
important work I've captured in both of the repositories I've run have been
websites. I'm very grateful for this feature.

 then
> offer one to three existing features that you believe need 
> improvement. Feel free to explain your answers at length! Also, please 
> let us know which version of DSpace you are running.

Repeating quietly to myself "no new features... no new features..."

The whole communities/collections model needs a rethink, I think.
Faculty I talk to find it confusing and unintuitive; they expect communities
to be able to contain items, and collections to be able to contain other
collections. (The latter is particularly important for some kinds of scoped
searching.) Perhaps following on from this, they expect to be able to make
changes to community information that only an administrator can make,
because there is no DSpace analogue to "collection administrator" for
communities. Finally, for our consortial-repository purposes it's not good
that only an administrator can change collection/item access policies. I
need to be able to hand that work out to librarians at our member campuses,
but DSpace won't let me.

I understand that DSpace is meant to be an archival system, but the model of
"metadata and bitstreams can change before final deposit, but not afterwards
except by administrator fiat" doesn't accord with user expectations where I
am. People make metadata mistakes and don't notice them until after
approving the submission. People upload bitstreams and want to swap them out
for better bitstreams. Stuff comes in through a variety of channels that
needs editing after the fact (authority control, anyone?). I spend a *lot*
of time -- much too much time! -- dealing with things like this, as well as
talking down irritated users who want to be able to fix these things without
going through me. I also end up editing metadata directly in the database
(yes, I know, bad bad me!) because one SQL query takes so much less time
than making the same change to forty-'leven items individually in the UI.

The input-forms.xml system of modifying forms needs an overhaul as well. One
problem with it is that not all repo managers have server access in order to
modify this file, but they're a lot closer to the content/metadata than the
IT professionals who *do* have access to the file. Another problem is some
really bad interactions with the hardcoded "big three" front-page questions
-- if you put date.issued in your input-forms.xml, but your depositor
doesn't check the "previously published" box, DSpace wags a stern finger and
won't let them proceed! (This is a serious problem for theses and
dissertations, which do have a date.issued but aren't colloquially
considered previously-published in many disciplines.) Finally, this file
doesn't have any conditional logic. It can't, for example, say "okay, if
dc.type is Working Paper, show these fields; otherwise, show those."
This makes it essentially impossible to simplify the forms in a
heterogeneous collection, which is an unhappy thing for usability.

Right, those are my three. Next?

Dorothea

--
Dorothea Salo dsalo at library.wisc.edu
Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218,
Memorial Library
(608) 262-5493
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general