User:Ckeene/Ideas for future versions of eprints

From EPrints Documentation
< User:Ckeene
Revision as of 07:07, 19 April 2008 by Ckeene (talk | contribs) (New page: == Long term : fit in with academic workflow == Academics make funding bids, do research, etc, then write a draft article, then submit to journal(s), get published. At the moment we 'bolt...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Long term : fit in with academic workflow

Academics make funding bids, do research, etc, then write a draft article, then submit to journal(s), get published.

At the moment we 'bolt on' to the end of this, but what if we could play a bigger role.

This may be controversial as in a sense it moves eprints away from being just a repository, and perhaps maybe instead of any extra functionality being put in to eprints, we look at what popular 'research process management' solutions are out there and see how we can work with them (integrate, api's etc). If we had a tool that helps people manage their biids and funding awards, lets them refer to old ones, and see the documents they produced as a result (which - just so happened to make those documents available to the world) then this may well appeal to many academics. Of course at this point eprints stops being what it is and becomes something else, so any moves to accommodate such things would need to be carefully thought out).

Allow users to be authenticated by an external system

See my email message from April 2008.

At the moment eprints can be configured to use an LDAP server for authentication. Eprints takes the user credentials and then passes them to the LDAP server for authentication.

Perhaps a more generic extension to this is to allow the our sourcing of authentication completely.

E.g. when authentication is needed, the user is redirected to a predefined webpage (probably on the Institutions website) which handles login, and can pass back to eprints a successful login and the username of the user who has logged in.

This is a little similar to what ezproxy can do and also, in a way, to how shibboleth works.

The advantage is that it would allow a wide variety of campus authentication systems to be used to authenticate eprints, and eprints does not need to worry about handling password (and being secure with them, which is a key issue!).

Auto covert MS Word to PDF

The ability to let users upload a Word file and eprints to turn it in to a PDF (and store both) would make help many users and make the system more attractive to use.

Telephone call..

Humanities academic: "err hi, I've hear you're the people to contact to put my research online, how do I go about it?"

eprints admin: "cool, you just need to find you final draft of your article, covert it to PDF, using any PDF tool such as Acrobat or PDFcreator, which you may need to install, if you have admin rights on your PC, and then...." [sounds of despair from other end of phone, caller hangs up]

Of course, academics hardly ever phone up with such enthusiasm, but this talk of complicated stuff doesn't make it easy. If there's some sort of *nix library/tool out there which eprints could use to convert on the fly MS Word files to PDF, then this would make it so much easier from the researcher's point of view. They just need to upload their Word file, and it's made available as a PDF to users.

Auto LOC classify

Eprints has a simple LOC based classification system setup by default. This is good, but researchers don't find LOC that easy to decide which category to use, and find it all a little complex.

If there was some way eprints could use some web based service to find a suitable LOC heading to suggest to the user, based on the journal/book title. (i.e. if there is a web service that can be passed a title or issn/isbn and return a LOC heading for that journal/book).

Auto submit to other repositories

"why should I deposit in the IR when I have where all my peers submit to as well?" "If I have to deposit to my Research Councils repository* why should I deposit to the IR as well?"

Good questions! and what if the answer was "By submitting to the IR it will automatically be uploaded to the other repository just by ticking a box"

With SWORD this should now finally be possible. This could be a killer feature and I think it could do more than just support the protocol. It should use logic to recommend other repositories that the user can just tick for it to try and submit the item to as well i.e. if user is a physicist suggest arXiv, or if item has been categorized as 'Econmics' then suggest repec, or if it has a co-author at Watford Gap University then suggest that it is deposited their as well.

Make document available in other formats

Similar in a way to the first idea. If someone deposits a PDF/PS/RTF then make it available in a number of file types, either converting it on the fly or perhaps converting it as it is deposited (use more space, but may have archival plus points'.

These are just my personal thoughts, partly based on feedback we've received from academics. Though the last idea was mainly due to Citeseer making documents availabele in many formats (e.g. Like I say, these are all non-trivial, but hope it makes for good food for thought!