You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Date & Time

  • July 14th 15:00 UTC/GMT - 11:00 EDT

Dial-in

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

Agenda

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?
  • Background:
    • Use Case Analysis 
    • Back in April, we took a stab at a similar question, attempting to get to a prioritized list of features. Discussing priority all the way down on the level of individual features and use cases was, in hindsight, probably too detailed.

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.

Meeting notes

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 focus on Journals, 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 it would be interesting if DSpace could manage Journals as well. DSpace being content agnostic is one of its prime features. Practical support for certain formats would only increase its usability.

In addition to this, it would be convenient to equip the core version of DSpace with additional plug-ins for media support, such as video or image viewers.

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 questionably 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 you think they are.

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 current mandatory hierarchical approach 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.

Call Attendees

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.