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 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?

Call Attendees

8 Comments

  1. Bram Luyten (Atmire)

    One of the things I personally recognize as unique to DSpace as an Institutional Repository is the variety in well developed support for:

    • Ingesting content from a variety of sources, formats
      • by human users (submission + workflow, batch CSV ingest)
      • by machines (SWORD, REST-API, deposit from CRIS systems)
    • Dissemination, making content available to
      • human users: responsive web user interface, RSS, email alerts
      • machines: OAI-PMH, Highwire press metadata tags (google scholar), REST API, 

    Even if something like the actual storage of bitstreams and preservation aspects would be handed off to another system/infrastructure, I think DSpace could keep the position as one of the most versatile options for the ingest + access to the content.

    I'm not sure to which extent the definition of "the content" should influence what we consider core. There is so much development outside of the "traditional" IR use of PDF contents into audio, video, datasets etc ... that I don't know if it would serve our community if we would put a certain definition of "content" into the core.

     

  2. Bram Luyten (Atmire)

    Jim Ottaviani - sorry that we weren't able to discuss the JISC publications router this time, would definitely recommend that we explore this in one of the future calls!

    1. Jim Ottaviani

      No worries. It was a last minute addition by me, and there was a lot to talk about on your original agenda!

      Briefly, I've been involved in some discussions with MIT and bepress folks about developing something along these lines, and I think there's potential here for developing some useful functionality and partnerships with publishers (OA and otherwise) and other organizations (possibly even SHARE) in terms of making so-called green OA articles more readily available to our repositories.

  3. Pauline Ward

    Bram asked about facilitating applying for trustworthiness certification , similar to the Data Seal of Approval, which we've just applied for in Edinburgh. My colleague Stuart Macdonald who compiled our application has these suggestions:

     - provide/or document an explicit mapping of DSpace processes and workflows to OAIS reference model (where and if applicable AND if they don't already do so!!!!)

     - provide means to facilitate file format migration reasonably easily 

     - build in standard file format identifiers and validators such as JHOVE2 and/or PRONOM

     - move from providing handles to DOIs 

     

     

  4. Nicholas Webb

    Hi all – thanks for a very interesting discussion. Some additional thoughts on the point made (IIRC) by Terry, that while core DSpace shouldn’t try to provide services that are better met by other software packages, providing a full out-of-the-box feature set is part of the DSpace appeal to small repositories (like my own) that lack the resources to implement an integrated suite of multiple systems:

    From my perspective, Technology Goal 5 (DSpace “just works”) is one of DSpace’s great value adds. It’s (1) open source, (2) works out of the box, and (3) provides at least “entry level” functionality for the major IR use cases. No other platform that I’m aware of meets all three of these criteria. Other open source repositories (i.e., FEDORA and its derivatives) require a much greater initial investment to get up and running, and while the digital preservation ecosystem is much larger than it was 5 years ago, DSpace is still the only “all in one” open source repository on the market. (Archivematica, for instance, is a preservation tool only and requires integration with an external access system to be fully functional.)

    This is why I think it’s important to clarify the semantic ambiguity around the “institutional repository” concept – a platform tailored specifically to disseminating research output implies a different feature set than a general system for digital object storage. Circa 2005-2010, there was a fair amount of discussion in the archives and special collections literature about the relationship between A&SC departments and the IR as an institution-wide function, but this has tapered off in the past few years – the most recent systematic survey of IR use by archivists was in 2008 (http://deepblue.lib.umich.edu/handle/2027.42/106421).

    A productive way of approaching this may be to ask: how can core functions can be defined with enough specificity to be useful, but enough generality to be flexible? Tim’s discussion of replacing the Community/Collection structure is a good example – IMO, a nested hierarchy of collections as a *logical* arrangement shouldn’t assume or imply a particular *intellectual* organization of content beyond the generic assertion that “Z is a sub-unit of Y is a sub-unit of X.” That’s a flexible enough model to encompass a traditional departmental structure for research repositories, a flat hierarchy like the one David described, and a situation like my own where we’ve ended up treating sub-communities as a “container” unit analogous to Encoded Archival Description’s <c> tag. Likewise with author pages – I’m not involved with research management, so that particular use case isn’t of interest to me, but if the data model for author pages was flexible enough to accommodate a range of descriptive use cases (say, via locally specifying metadata fields in the same way that collections are specified by input-forms.xml), I could see myself using it to store archival authority records.

    @Pauline Ward, +1 to this list of suggestions. We don’t have immediate plans for formal certification, but I’ve been using TDR as a guide to best practice in developing workflows, so formally modeling DSpace in terms of OAIS is actually a project I’ve been meaning to do for some time now. I won’t have much time to spend on it until the end of the summer, but if other people agree that it would be useful, I’d be willing to work on this as a volunteer documentation project.

    1. dschuster

      We adopted this as we needed a solution and it was the easiest way to "demonstrate" how Repositories can be a good thing.  Bringing it up was easy, and keeping it up so far has not been too much work.  

  5. Amanda French

    So sorry I had to miss this! Thanks for the notes. Will carve the next call in stone.

  6. dschuster

    Author profiles and its Relation to CRIS - Our faculty are "new" to open access and showing how this benefits them has been difficult if they didn't understand it.  Having a tool like CRIS "as an option" for DSpace at least will keep them coming back.  If they have to "do one more thing" and <b don't understand /b> how it benefits others and themselves(IR) it is a step in the publishing process they would rather ignore.  They are too busy already.

    Many repository managers are doing the ingesting of works for faculty, but if we can provide a secondary benefit like CRIS and get the research office involved, I would hope having faculty do their own submissions may be easier to attract.  This would be an interesting study by someone how has DSpace and then implements CRIS and the change in volume and who is managing the workflow.

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