Hi Tim, (copy to Michele, Dorothea and the Tech list)
Thanks for your views and congratulations for your work with IDEALS.
Just to be sure to be well understood: I am not in any way proposing to
disturb developpers, I am speaking about organising USERS so they
express their needs, build concensus and propose developers to build
prototypes they can evaluate. I am also proposing to organize better the
commitment process to improve consistency and reliability. This will ask
for inter-institutional efforts so I also propose institutions to
finance parts of those processes. This is the key of adequation and
perenity.
I am not saying nothing of this is done now, I am just proposing this to
be improved under the drive of the Federation.
Wishing you and all a very nice day!
Christophe Dupriez
Tim Donohue a écrit :
All,
As a Committer, I'm going to go ahead and step out on limb here, and
admit that I agree with most of what has been put forth by both
Dorothea and Christophe. That being said, I'm not claiming to speak
on behalf of all the Committers :)
I would *love* a more beautified DSpace...a clean, "flashy", web-2.0
interface, a modular system that is easy to extend via
plugins/add-ons, an *easy* way to share/install those plugins/add-ons
between institutions, and an *easy* way to upgrade core DSpace
(without merge nightmares between your local hacks/customizations and
the features of the new version).
I'm also in full support of working towards better needs assessment.
But, at the same time, a part of me feels that different institutions
will have some different needs based on how they are using of DSpace.
So, in the end, allowing for easy extensions/modules, and easy sharing
of these community-developed features is a great way to go.
That being said, I'd like to mention just a few things to look forward
to with 1.5 and beyond:
1) I believe there will be vast strides to beautifying DSpace UI, once
we all get our hands on Manakin in 1.5 (many thanks to Scott P & all
at Texas A&M). The modularity within Manakin should also allow us to
all develop new an interesting Themes & Aspects, which should be much
more shareable amongst institutions. (But, we also need to find a
place to actually post these for sharing!)
2) I believe that our move towards the Maven build system (thanks to
Mark D) with 1.5 will be a huge step in the right direction for better
modularity within DSpace, and better separation between the core API
and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.). There are
still a few kinks here, but we're learning quickly and attempting to
make things easier to manage as separate modules (and also easier to
upgrade!). The goal here is to hopefully help allow
community-developed customizatins/add-ons to flourish and not be a
continual pain in managing/updating. In addition, we want to make
them more easily shareable between institutions (i.e. without the pain
of merging local code, etc.). I'm not claiming this will all be
figured out or 100% perfect in 1.5...but, it is a goal I'm hoping we
can get to by 1.6 or 2.0 (or whatever comes after 1.5).
As a Committer, I also feel obligated to mention that the Committers
are all volunteers. We are working hard to make DSpace better for
all of us, but there's only so much we can do (and largely our
development work is defined by our the individual interests of the
institutions which pay our salaries). Therefore, DSpace is still
dependent on new features/ideas/functionality being proposed &
developed/prototyped by an active user community. The Committers may
be able to step in and help out (when their institutions allow), but I
believe an active community is still necessary. Remember, the
Committers are often just highly-active community members! Case in
point: I was only asked to become a Committer after my giving back to
the community (in the form of DSpace tutorials and Q&A on listservs),
as well as the large amount of work in designing, re-designing &
developing the Configurable Submission (which my institution allowed
me the opportunity to take on).
I'm really glad to see these discussions taking place! It means we do
have people in the community who care strongly about DSpace and are
willing to share their opinions and suggestions for moving forward. I
encourage you to continue to help drive DSpace in the right direction!
Ok...that's my diatribe or rather long $0.02 :)
- Tim
Christophe Dupriez wrote:
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
-------------------------------------------------------------------------
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
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