Hi !
At PoisonCentre.be, we use DSpace for scientific (medical) information
collection, organisation and internal re-publication, e.g. Knowledge
sharing (not ETDs)!
I find rather funny that this discussion occurs in the technical thread
and not the general one.
The technicities are the reasons we meet, the subjects vary!
I share most of Dorothea opinions.
I strongly support the creation of a DSpace group for user needs assesment.
The output of this group should be:
1) use cases,
2) value of thoses use cases for the institutions we represent,
3) essential "user side" characteristics of the corresponding
functionalities those uses cases imply.
From there:
1) a "designer board" could propose functionalities (no buzzwords!) to
fulfill those needs.
2) developpers would be invited to find "mentors" within the users
groups and to produce a prototype.
3) User group would then discuss prototypes results and would choose
those that must be worked further for inclusion in DSpace trunk.
4) Committers would work on "mature prototypes" (user proof) to make
them 100% compliant to DSpace architecture and coding standards.
IMHO, this process should be tightly driven by the Foundation and
financed by institutions taking advantage of DSpace know how, technology
and emulation.
It seems to me that project IDEALS is an example of this:
https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/RequirementsProduction
An example of the "users requirements" challenges we could achieve for
DSpace:
http://www.vufind.org/
http://zoombox.gmu.edu/vufind/
For my institution, I need now to fulfill the challenge of crosslinking
different DSpace instances (or collections) to have one serve as an
authority list for some fields of others (and to use those relations in
searches).
Have a nice day!
Christophe Dupriez
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Dorothea Salo a écrit :
On Nov 13, 2007 1:23 PM, Susan Teague Rector <[EMAIL PROTECTED]> wrote:
Our debate here is centered on future support of ETDs in DSpace. We've
had to do quite a bit of customization to support ETDs (thank goodness
for Tim Donahue's code :)! Does anyone know if there are future plans to
better support ETDs in DSpace?
With the understanding that I'm not a DSpace committer and not
involved in any way with DSpace or the DSpace Foundation except as
DSpace user and occasional bug or patch submitter...
My sense is that DSpace development has only vaguely and loosely been
guided by real-world use cases not arising from its inner circle of
contributing institutions. E.g., repeated emails to the tech and dev
lists concerning metadata-only deposits (the use case there generally
being institutional-bibliography development), ETD management, true
dark archiving, etc. etc. have not been answered by development
initiatives, or often by anything but "why would you even want that?"
incomprehension or "just hack it in like everybody else!"
condescension.
There are hacks for some of these uses, yes... but from a sysadmin's
perspective, hacks endanger smooth upgrade paths, and from the
perspective of many librarians, hacks are entirely out of reach
because IT rather than the librarian controls the box DSpace lives on.
When innovation has occurred around DSpace, it has generally died on
the vine because of the aforementioned threat to smooth upgrade paths.
TAPIR and Researcher Pages may serve as the requisite gruesome
warnings here; they died not because the ideas underlying them were
bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't
have had to ask the question she just did!), but because almost nobody
dared adopt them. I see all kinds of nifty conference presentations
involving DSpace mods -- but they provide me no practical benefit
whatsoever, because the code isn't out there and I probably couldn't
use it if it were!
DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti
dinner under its hood, has stifled service innovation in the
repository space for years, and will continue to do so until the
defect is rectified. Neither EPrints nor Fedora is in a much better
position just now, but in all honesty, I predict that the first
platform to *have* a half-decent mod API (especially one that welcomes
mods written in friendlier languages than Java) will experience an
explosion of innovations that will eat the other platforms' lunch.
Manakin assuredly helps, but not quite enough.
SWORD may also help, rather backhandedly, by providing an ingest path
that doesn't rely on the horrendous web UI or the awkward batch
ingester. We'll see; I'm hopeful. I'd far rather build an ETD app that
used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs
myself, much less try to push the committer group to do so.
It may be worth noting at this point that I put my votes where my
mouth is; when the DSpace development survey came out, I put a mod API
at the very top of my desiderata. I encourage other repository
managers with unmet needs to speak up for this! It's vastly more
important for the long-term health of DSpace and the services we are
building around it than are (for example) controlled vocabularies.
Dorothea
begin:vcard
fn:Christophe Dupriez
n:Dupriez;Christophe
org:DESTIN inc. SSEB
adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 1;Bruxelles;;B-1030;Belgique
email;internet:[EMAIL PROTECTED]
title:Informaticien
tel;work:+32/2/216.66.15
tel;fax:+32/2/242.97.25
tel;cell:+32/475.77.62.11
note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de Traitement de l'Information
x-mozilla-html:TRUE
url:http://www.destin.be
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
