LibreCat Call 2019 08 29

LibreCat kickoff meeting.

Time 15:00 - 16:00

Place: https://meet.jit.si/LibreCat

Agenda

Setting a roadmap for the next release

Participants

• Vitali Peil
• Jochen Schirrwagen
• Nicolas Steenlant (not available)
• Patrick Hochstenbach

Call highlights

• We keep a monthly call every month
• Tentative technical meeting in December or January in Bielefeld
• Next meeting 26 september 2019 15:00
• Homework: create a local short list of short term goals (for 2.1 release) and longer term (for 2020 Q4)

Context

Bielefeld requirement

• GitLab integration
• CRIS integration
• Split front-end from backend

UGent requirement

• Forms generation
• Server based validation only
• IRODs integration
• Workflow integration
• Reporting integration
• Smaller code base
• Audit tracking by default (and viewable in the interface)
• Possibility to have a versions conversation attached to a record (to track reviewer remarks edits)

Inspiration from Open Repositories 2019

https://lecture2go.uni-hamburg.de/l2go/-/get/l/5134

Sword protocol support?

Pro:

• Looks very good in slides to be able to have a standards based migration tool
• There isn't really on standard way to import data in LibreCat now (no MODS/MARC etc upload)
• Sword 3 seems to be a better behaved protocol than earlier versions

Con:

• Sword is certainly not a replacement for out own REST api. Example DSpace: they required to implement their own REST api to be able to use Angular JS in their DSpace 7 frontend
• I don't know if there are actual clients using Sword in production
• I don't know if supporting Sword really means supporting all the versions (for all possible clients)

Statistics

• Seen in EPrints. They have out of the box very nice statistics pages for all data available in the repository. It would be nice to have something R / (Shiny) like to be able to have local extension. I don't think any local 'customer' will go into Perl statistics programming

Flavours

• Seen in EPrints. We have layers to have customizartion. EPrints has layers and something in between flavour. It is a custom, out of the box, layer tuned for a specific use case. E.g. the students paper repository, the image database respository. This way some of our own customizations could be part of the general code base.

OCFL

• Oxford Common File Layout. DSpace, Fedora and other are all planning to move to this way to store the files on disk. It provides a versioned way to store data and looks a bit like BagIt but with JSON manifests files and metadata.

Hiearchical classification

• We currently have 2 ways to classify records: via departments and projects. We need a generic way to create any custom deeply nested collections and be able to let records be part of that tree.

Configurable workflows

• Part of DSpace 6
• Task reporting. Make a dedicated interface for admins to review the tasks that need to be done to repository record. Preferably use an external task tool to interface with

Licenses on file level

• The people working with research data stress this as a requirement: every file attached to a record could have another license file. E.g. the software packages has an MIT license, the documentation is Creative Commons.

OR2019 Repository Platform Census

• 60% DSpace (Java)
• 10% EPrints (Perl)
• 5% Fedora (Java)
• 4% Invenio (Python)
• 3% Dataverse (Java)
• 18% Something else
  • 9% in house
  • 2% Hyrax (Ruby)
  • 1% Hydra (Ruby)
  • 1% Haplo (Java/Ruby) https://www.haplo.com/ https://github.com/haplo-org/haplo