We will use the international conference call dial-in. Please follow directions below.
Discussion: Fundamentals of the modern Institutional Repository use case
What should be considered as "core" to DSpace and what shouldn't.
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
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:
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.
This statement could be split up in two different domains:
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.
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.
Bram Luyten - @mire