Support for showing BibSonomy/PUMA bibliographies (via REST API)

1 Initial Problem

Both BibSonomy and PUMA are Web-based open-source publication/reference management solutions. While the former is chiefly what drives the public site bibsonomy.org, the latter is meant for on-premise hosting at university libabries. As such PUMA is the central publication management solution at the Universitätsbibliothek Stuttgart where, among other things, it is used to maintain the university’s central bibliography (Universitätsbibliografie).

While there exists a PUMA plugin for Moodle (and “feasability implementation” of a plugin for ILIAS that currently is not publicly available), ILIAS already has the Bibliographic List Item to display bibliographies uploaded from .ris, .bib and.bibtex files. If possible we’d like to expand this capability to suppot the BibSonomy/PUMA REST API to dynamically display bibliographies from these systems (instead of introducing an additional repository object with — from an end-user point of view — basically overlapping functionality).

Some reference material:

• bibsonomy.org
• PUMA
• BibSonomy code repo
• PUMA code repo
• BibSonomy API documentation
• PUMA plugin for Moodle (“pbm“)

BibSonomy and PUMA basically share the same API. We will try to amend information about additions that are only present in PUMA (if any).

2 Conceptual Summary

The “PUMA connector” should retain all the functionality the bibliography list item already has while adding the possiblity for dynamic read access to PUMA/BibSononmy bibliographies. The ILIAS RBAC controls who in turn has read access to the bibliography list item as is. Additionally desirable would be some kind of “overview functionality”.

2.1 Making a bilbiography available

Users should be able to select the source (ie. bibsonomy.org, a local PUMA instance or perhaps another BibSonomy instance) for each bibliography object from a preconfigured list (compare Administrative necessities blow).

On the other hand user authenticaltion of course should not have to be repeated over and over on a per-object-basis. The ILIAS plugin mentioned above (and probably the Moodle plugin, too) intended for the individual user to enter her/his PUMA API key(s) and/or OAuth token(s) into (a) custom field(s) in the personal profile in ILIAS before being able to effectively use the plugin (object). I’m not sure this is ideal from a UX point of view, but I’m (at the time of the inital draft of this entry) not sure whether a more “central” authentication (eg. like the Adobe Connect plugin employs for communicating with the DFN connect server via a central API account, using the users’ e-mail addresses for individual ID) is viable with BibSonomy/PUMA, either. (This will have to be clarified.)

Users should be able select an individual (BibSonomy/PUMA) bibliography (list), a group or a tag as source to be (dynamically) displayed in ILIAS.

Important: The citation style should be inherited from (the) BibSonomy/PUMA (list/group/tag).

2.2 Consuming a bibliography

For consuming users additionally to the exisiting functionality (export, detailed view, ReDIS links) links back to the entries in BibSonomy/PUMA should be provided (if public).

Also, as far as I unstand the bibliography object at the moment offers to download the “orignal file” — which in case of a dynamic BibSonomy/PUMA list of course does no exist as such. So the user probably should be able to choose a download format (either .ris oder .bib(tex)?).

2.3 Overview functionality

Additionally our colleagues from the library wish for an “overview feature” that enables them to see which titles are recommended/required in courses. Since a GUI solution at the moment seems non-trivial to me (at least in terms of “where to put it”) I propose to solve this via a cron-job that generates an e-mail summary (eg. weekly, to addressed entered in the bibliography administration).

For the quote I’d like to keep this requirement optional (for now).

2.4 Administrative necessities

The bibliography list item administration needs to be extended to activate and configure the BibSonomy/PUMA support and to manage instances/API endpoints the can be then selected by the users when creating a bibliography objects.

If the “overview feature“ (see above) is to be implemented [as a “mail cron-job”], receipients for the summary mails need be configurable. (Alternatively this probably might be done in the cron administration.)

2.5 Technical aspects of implementation

(The details of the implemenation have to be fleshed out together with the maintainer.)

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: Bogen, Christian [bogen]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

7 Discussion

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.