Child pages
  • ResultsSummary
Skip to end of metadata
Go to start of metadata


DSpace is an open source digital repository application.
We evaluated the internal Java interface used by the DSpace application,
not the Dspace application.
See DSpaceFeatures for a full evaluation of the API.


  • Easy to use


  • Not intended as a public repository API.
  • No commitment from the DSpace project to maintain the API.
  • Use of API must be performed from the repository host machine.


Fedora is an open source web services based framework
for managing and delivering digital content.
We evaluated the web service interface provided by Fedora.
See FedoraFeatures for a full evaluation of the API.


  • Flexible architecture
  • Programming language agnostic


  • Complexity of development

Digital Commons


  • No server hardware or software required.


  • Designed to support end-user functionality, but does not support application integration easily.

JSR 170

JSR 170 is a Java repository API
developed through the Java Community Process.
There are open source and commercial implementations of JSR 170.

See JSR170Features for a full evaluation.


  • Feature rich
  • Stable API based on published standard.


  • Completely tied to Java and Java technologies


ECL is an implementation of the IMS DRI specification.

See ECL_Features for a full evaluation.


  • The provided connector simplifies implementation of this complex protocol.


  • Intended for use primarily with learning object repositories.
  • Detailed information on implementation is difficult to locate.


The OKI Open Service Interface Definitions (OSIDs) provide an interface or boundary between service providers and consuming applications. The DR OSID addresses digital repository service interfaces.

See OKI_OSID_Features for a full evaluation.


  • Bindings are or will be available for a variety of programming languages.
  • Stable API based on published standard.
  • No labels


  1. Anonymous

    Are there no Cons to OKI-DR ?

    1. I didn't see any major cons, and didn't want to think one up just to have one. However, I am not a repository programmer, and so am not deeply familiar with the kinds of issues actual implementation would expose.
      Our methodology developed a list of functionalities. The analysis was simply to describe ways that the OSIDs could be used to provide access to the various required functions. I only included things which I could point to explicitly in the published documentation. A careful reader with specific questions about search for example, at a granularity finer than our rubric, might find that a particular search functionality may not be present. That said, I did leave some things blank where there was no correspondence with the OSIDs, and did mention that removal of old versions of an asset was not addressed in the OSIDs at all.
      It is likely that there are Cons to actually using the OSIDs, but the issue of implementation is beyond the scope of the analysis - we were just mapping functionalities to the interfaces.