Date & Time
- July 14th 15:00 UTC/GMT - 11:00 EDT
We will use the international conference call dial-in. Please follow directions below.
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial in #
- Once on the call, enter participant code 2257295
Discussion: Fundamentals of the modern Institutional Repository use case
- Focus on Institutional needs (reporting of the institution members for scientific activity??)
- Consider different perspectives (end users, authors, co-authors, repository managers, research managers, funders)
- Funder monitoring (using existing API of OpenAIRE for funder compliance and monitoring) - Addon - https://gitlab.fccn.pt/dev-rcaap/addon-openaire/tree/OpenAIRE5.X
- Extended metadata schema - hierarchical metadata exposed - CERIF-XML ? (considered on the use cases).
- Metadata improvement by the submitter after deposit (with internal validation) ?new feature?
- What is the position of the Institutional Repository (of DSpace) in the landscape of other, similar software?
- Related reading: DSpace Positioning
What should be considered as "core" to DSpace and what shouldn't.
- Should we consider only for discussion the "Institutional Repository" ?
Proposed agenda item: Is there any interest in getting behind developing something akin to the JISC Publication Router? (Jim O. can say more about this if there's interest and time)
Discussion format: to be determined
Preparing for the call
Please prepare to give your opinion on what should be considered "core" to DSpace and what shouldn't. Think about questions we may ask ourselves or eachother to come to a better understanding of the boundaries. Feel free to use the comment sections below to put down your raw or processed thoughts on this.
In future releases, DSpace will focus on the fundamentals of the modern "Institutional Repository" use case. This is what we have been referring to as as the core functionality of DSpace. This core functionality will be based upon the use cases we have gathered in the past and which were analysed during the use case analysis.
We already discussed the prioritizing of those use cases in April. Back then it was clear the sheer amount of use cases and the multitude of persona's involved did not make this prioritizing easy.
During July's meeting we adapted a more high level approach. Instead of going into detail, we discussed general features to include in future versions of DSpace.
We discussed following topics elaborately:
Managing Journals: Should DSpace enable Journal management, as there are many other tools available?
It could be interesting to optimize the integration between DSpace and third party tools like OJS. This raises the question however what DSpace should still be doing, as much of its functionality could be done by other platforms. Secondly, for some institutions running two or multiple systems in parallel could be to much complexity for what they are trying to do.
In general we could conclude DSpace should not try to compete with platforms like OJS. When it comes to Journals it should act merely as a preservation tool, as it is the case for all other formats as well. A focus on integrating with Journal management tools would thus be more appropriate.
DSpace being content agnostic is one of its prime features. However, practical support for certain formats would only increase its usability. Therefor it would be convenient to extend the core version of DSpace with additional plug-ins for media support, such as video or image viewers. A similar plugin could be developed to export selected items as an overlay journal.
DSpace should become a trusted repository
This statement could be split up in two different domains:
- How Managers manage content: managers should maintain content adequately
- How DSpace manages content: The platform should be equipped with maintenance and preservation technology.
For the latter it is important to prepare DSpace for long term preservation and equip it with optimized curation functionality. For example: DSpace should be capable of checking for incompleteness in metadata. Reports of this checkup should then be provided to the administrator who can correct the metadata.
Should DSpace have author profiles?
There are already many scientific platforms allowing people to create profiles. It is also questionable where the creation of profiles would end. Do we also want profiles for publishers or funders, for example.
On the other hand, end users would like such profiles. It bonds authors to the repository and may improve their attitude towards it. Such profiles could also act as an identifying mechanism that an author is genuinely the one a user is looking for, and not a namesake.
Such profiles could also show statistics about the author, and list all publications they submitted.
We also addressed more briefly:
- More things should be editable in the admin UI
- DSpace needs versioning for data files
- Greater flexibility in datamodel: This issue will definitely be addressed. Instead of the currently mandatory hierarchical datamodel there will be one type of collection which can be used to create one's own hierarchy. Items could then be submitted everywhere in the hierarchy.
- DSpace needs more tools and functionality for collaborative work on projects
- DSpace should continue to work out of the box
- Should DSpace focus on archives and special collections?
Bram Luyten - @mire
- Ignace Deroost - @mire
- Maureen Walsh - Ohio State University
- Lisa Johnston - Univ of Minnesota
- Terrence W Brady - Georgetown University
- David Isaak - Kaiser Permanente
- Jose Carvalho - University of Minho
- Jim Ottaviani - University of Michigan
- Nicholas Webb - Mount Sinai Health System
- Tim Donohue - DuraSpace
- Susan Borda - Montana State University
- Leila Sterman - Montana State University
- Pauline Ward - University of Edinburgh
- Iryna Kuchma - EIFL