Date & Time

  • Main call Nov 18th 16:00 UTC/GMT - 11:00 ET 
  • Satellite call Nov 19th 21:00 UTC/GMT - 16:00 ET 

What is the difference between the "main call" and satellite call? 


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:
    • 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

2014 Meeting objectives

From August until December 2014, the monthly DCAT meetings are centered around defining, refining and prioritizing DSpace use cases.

These use cases are expected to have an important impact on the medium and long term roadmap of DSpace, starting with DSpace 6 in 2015.

November Meeting Agenda: Integration use cases

During the November meeting we will be discussing integration use cases. Which kinds of use cases are supported by a more advanced integration between DSpace and other systems than the ones existing today? Should these integrations be one-directional, bi-directional? What kind of user interface (if any!) should come with these integrations?

 For each of the needs that emerge, we will try to qualify those needs as:

  • Supported: the use case is being addressed and that the bulk of configuration associated with it (if any) can happen through the UI.
  • Partially supported: there is room for improvement in the support for the use case. It also covers the cases where specific server configuration or small customizations to the code are required in order to properly support the use case.
  • Unsupported: if at all possible with DSpace, addressing the use case requires substantial modifications to the DSpace sourcecode.

We rather want to cover more use cases than to stick to a limited number, allowing to dig deeper in detail. This is why we will be asking the participants in the call for their institutions or personal priority after devoting ~5 minutes to a explanation and discussion about the actual use case. This means we hope to cover at least 10 use cases during the call. 

Read more about certain use cases that were already identified: Use Cases

The best way to participate and contribute

If you have some time to spare to prepare for this meeting, it would be great if you could briefly list the most important administrative use cases for you or your institution, especially if they fall in the category unsupported.

  1. Sign up for an account on this wiki and log in.
  2. Put your use cases in the comment section of this page. 
  3. Join either the main call or satellite call and tell us about your use cases 

Discussed use cases


Call Attendees (main+satellite)

  • Bram Luyten (@mire) - @mire
  • Maureen Walsh - Ohio State University

  • Ignace Deroost - @mire
  • Terry Brady - Georgetown University 

  • Pauline Ward - Univ of Edinburgh

  • Valorie Hollister - DuraSpace

  • Sarah Potvin - Texas A&M
  • Emilio Lorenzo - Arvo Consultores
  • Richard Rodgers - MIT
  • No labels


  1. Integrations that significantly lower the effort to fill DSpace with content

    • (Semi-) automated ingest from sources that hold bibliographic information
      • Third party platforms:, Mendeley, Google Author profiles, ORCID Works
      • In-house systems: Library catalog, archives, special collection systems (depending on which content you want to get into DSpace)

    Integrations that increase the exposure of content stored into DSpace in external systems

    • Exposure of content according to standards defined by external organisations
      • Europeana
      • Resourcesync
    • Making it easier for faculty to push content already in DSpace to third party platforms such as, Mendeley, Google Author profiles, ORCID Works

    Integrations that avoid registering information multiple times within the organisation

    • Import & export to CRIS systems and other institutional reporting tools


  2. In-house systems: student management system (thesis submission),  RDM systems (could be external too, e.g. Figshare) - linking to underlying data and vice versa.

    We (and most institutions in Norway) also use the CRIS for submission of content - so not sure which heading is best here.

  3. Here are some additional integrations that could exist
    • Learning Management System Integration (example)
    • A/V Streaming Service
    • Document Streaming Service
  4. I'll second Terry's ideas of document and A/V streaming, but I have one of my own for consideration.

    This is an integration that increases content exposure via external systems:

    • An oEmbed service that consumes DSpace search results (Discovery) so that content can be inserted into an external webpage via standard object embedding or iframes, in the same way one can embed YouTube videos and such.  The reduces the development burden on content users who maintain their own sites but would want to keep updated lists of repository content on their sites.


  5. At Edinburgh, PURE is the main institutional CRIS we are using, so facilitating transfer of datasets and citation information from PURE to DSpace would be a priority for us.


    However, I think there might be benefit in also looking at facilitating the transfer of data from discipline-specific systems like Seek for Science or OpenBIS (life sciences) into DSpace. Research groups would be using Seek for Science to share their work with each other and for the social networking features, and then might want to take a snapshot of that data eg when they were preparing a publication, and put it into our DSpace repository.

  6. Support for the management of very large files:

     - Loading very large files into DSpace. We discovered recently when we were doing a batch import a size limit of 3Gb at the virus checker stage. 

     - Access for users via browser or other means to very large files. There can be risks of overload to the host server if users connecting through the internet from a slow network attempt to download very large files. Integration with Academic Bit Torrent might help mitigate this risk...?

    1. Oops P.S. and Bram also referred to managing storage as large files are accumulated.


  7. We are concerned here with potential integration with Fedora and VIVO. Possibility of sending rich author information from VIVO into DSpace, pulling publication information from DSpace into VIVO. This is just the tip of the iceberg, it sounds like it would be helpful to have more detailed use cases about these integrations. 

  8. Also integration that will support linked data. Ability to query and store data stores from DSpace and retain this as both a displayed value and a URI. Bram raises the example of integrating geographic metadata with GeoNames. Ability to expose DSpace metadata as linked data.

  9. Integration with preservation systems and tools, including the Digital Preservation Network, fixity checks, and other support for preservation management.

  10. Sorry I couldn't make yesterdays meeting. Also I wanted to add a +1 on the integration with library catalogue. We will be considering integrating DSpace with Alma for better metadata management, e.g. authority control.

  11. Sorry I missed the call yesterday.  +1 with SarahP on the need for some more detailed use cases for this one.

    We would be looking to provide integration with external data stores potentially, particularly to harvest metadata + links to datasets

    We already integrate with Symplectic CRIS for deposit of publications metadata + full text, but I'd agree there are questions about large files for other output types

    +1 with Elin on integration with discovery tools/catalogues


  12. REST API opens the door to many types of integration.

    Ex: This XMLUI site: has a rest api, and a client application (new user interface) can read from API, support authentication, and allow user to create content:


    DSpace 5 adds RDF / Linked Open Data support:

    SPAQRL endpoint:*:*  (Pascal Becker understands how to query this better)


    Another LOD project (not DSpace 5, but DSpace-Oceanlink), which looks different is:

    An example SPARQL query is:{%20?node%20%3C}%20LIMIT%201