User:Ckeene/Ideas for future versions of eprints
- 1 Long term : fit in with academic workflow
- 2 Allow users to be authenticated by an external system
- 3 Enhance the concept of authors (and editors)
- 4 Auto LOC classify
- 5 Auto submit to other repositories
- 6 Refine search / facet search
- 7 Make document available in other formats
- 8 Things that have made it in to Eprints 3.1
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. (actually I don't really have a clue what academics do, but hopefully this is a good guess!)
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 http://www.oclc.org/us/en/support/documentation/ezproxy/usr/cgi.htm 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!).
Eprints has a type of person called a 'depositor'. they can log in, submit stuff, have a profile, list what they have submitted, etc. Nice.
But Authors as a concept does not really exist. they are just bits on text strings in the system. Sure, we can generate a view of all authors (often so large and with variant entries that it is of limited use).
Having an 'object' for authors would allow, for example, one REAL Author to have multiple display names, so that if one paper has them down as "C Keene" and another as "Prof C.J.Keene" eprints can still treat them as the same person, even if they show up differently on different papers. It allows for clever things, like allowing other systems to have a list of one person's research (not just research that so happens to have the same name attached to it, how many John Smiths work at your Uni?). And perhaps in the future it would allow 'Authors' (not just depositors) to login and see everything of theirs in the repository (everything they have co-authors, not just deposited) and 'do stuff with it'.
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 arxiv.org 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.
Refine search / facet search
See an example on the left of this worldcat page.
On search results, allow people to refine by year, author, department, type, with-full text, published, peer review, etc.
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. http://citeseer.ist.psu.edu/lagoze01open.html) Like I say, these are all non-trivial, but hope it makes for good food for thought!
Things that have made it in to Eprints 3.1
Auto covert MS Word to PDF
[April 08n update: this looks like it is a plugin in 3.1, excellent]
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.
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.