Output – FAR – Adding Shibboleth to DSpace With CASAK

Output Name: Output – FAR – Adding Shibboleth to DSpace With CASAK

Title: Adding Shibboleth to DSpace With CASAK
Number of pages or page numbers: webpage

Date Released: unknown

URI for Output: https://dspace.far-project.lse.ac.uk/casak-shib.html (report) for

patch – https://saffron.caret.cam.ac.uk/svn/projects/far/trunk/

Summary of contents:

CASAK is a patch for DSpace which allows container auth to be integrated into DSpace. It provides a number of mapping and filtering facilities to transform data provided by the container into a form suitable for DSpace. These facilities are generally inferior to those available within the SP, but for simple cases the configuration is perhaps simpler.

Configuring CASAK to use Shibboleth is therefore simpler than many use-cases of CASAK.

The approach used here contrasts with that used in MAMS in that CASAK is not Shibboleth specific, and has been designed to make a range of container auth solutions possible with CASAK. The purpose of this was to increase the long-term sustainability of the patch by extending its application to as broad a user-base as possible.

Output – FAR – LDAP server containing sample users with these attributes

Output Name: Output – FAR – LDAP server containing sample users with these attributes

Title: LDAP server containing sample users with these attributes
Number of pages or page numbers: webpage

Date Released: 29 June 2008

URI for Output: https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/FARProjectDemonstratorArchitecture

Summary of contents:

Technical description of the FAR Demonstrator Architecture.

Output – FAR – FAR attribute requirements report

Output Name: Output – FAR – FAR attribute requirements report

Title: FAR attribute requirements report
Number of pages or page numbers: webpage

Date Released: 19 August 2008

URI for Output:  https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/AttributeUseReport

Summary of contents:

  • Requirements for specific attributes to be used for Federated Access Management (FAM)-mediated access to repositories are not necessary because repository products use groups for access control already
  • It is recommended that group membership information is structured in attribute stores on a per-user basis (with a user object containing a list of groups of which the user is a member) as opposed to solely as a per-group basis (with a group object containing a list of members)
  • The use of groups for authorisation means that it should be possible for FAM to continue to be applicable with the introduction of new features to repository software

Output – The Depot – Service and Project Websites

Title: Depot websites providing a full range of supporting documentation

Date Released: June 2007

URI for Outputs:

http://depot.edina.ac.uk/FAQ/ and


Summary of contents:

FAQ section on the project website and ‘manage deposits’ section of the service website.

Additional information:


There’s a significant amount of overlap between the project and service websites for the Depot, and the repository itself, so I’ve just listed both websites here. The FAQ section is the main area where supporting documentation is provided on the project website along with the ‘manage deposits’ section of the repository service website.

Output – The Depot – UK Repository Junction

Title: UK Repository Junction

Date Released: June 2007

URI for Output: http://depot.edina.ac.uk/junction.html

Summary of contents:

‘UK Repository Junction’ is a re-direct service to ensure that content that comes within the remit of an existing institutional repository is correctly placed.

Additional information:

The service is essentially part of the functioning of the Depot service quality repository (separately listed as an output).


On testing the redirection using the example of the University of Bath which has it’s own repository, the junction worked correctly.

Output – The Depot – Service Quality Repository

Title: The Depot Service Quality Repository

Date Released: Approx November 2007

URI for Output: http://deposit.depot.edina.ac.uk/

Summary of contents:

“The purpose of the Depot is to enable all UK academics to share in the benefits of open access exposure for their research outputs. As part of JISC RepositoryNet, the Depot is provided as a national facility geared to support the policies of UK universities and national funding agencies towards Open Access, aiding policy development in advance of a comprehensive institutional archive network”

The Depot offers the following features:

  • a re-direct service, nicknamed UK Repository Junction, to ensure that content that comes within the remit of an existing institutional repository is correctly placed.
  • accepts deposit of e-prints from researchers at institutions that do not currently have an Institutional Repository (IR). The principal target is postprints, that is articles that have been peer-reviewed and accepted for publication.
  • as  institutional repositories (IRs) are established, the Depot will support the transfer of relevant content to help populate those new IRs.  Meantime, the Depot will act as a keep-safe, notifying  institutions when deposits are made.
  • an OAI-compliant interface, so, like other open access repositories, its contents is available for harvesting, with special attention being paid to ensure that it can searched through the Intute Search, another part of JISC RepositoryNet.

Additional information:


I created a Depot account and submitted a test item for the purposes of assessing the repository on the 27th November 2008. The was later removed. My observations following this are:

  • The repository browse functioned well and was responsive. The repository in general was working well.
  • When submitting an item, the submission page annoyingly scrolls to the top on opening hidden metadata fields (Firefox 3.0.4 , Mac OS X 10.5.5).
  • The submission process is lengthy.
  • No subject matches found for ‘jazz’, ‘journalism’ or ‘music’. Seems odd.
  • The process of adding a new version of an existing item is convoluted and tricky.  Similar for deletion – not intuiative.

The Depot repository would appear to match a large number of repository benefit and role categories, all of which are self evident. Feedback would be welcomed on these.

Project – EIDeR

Project Name: Enhanced ingest to digital e-research repositories (EIDeR)

Programme Name:Repositories and Preservation

Strand:Interoperability Demonstrators

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/interoperabilitydemos/eider.aspx

Project URI: no URL available at present

Start Date:1 April 2008

End Date:1 March 2009

Governance:JISC integrated environment committee

Contact Name and Role: Karen Stanton, Russell Burke, Vijay Albuquerque (King’s College London)

Brief project description: EIDeR aims to develop a demonstrator that implements enhanced deposit and ingest for institutional repositories (IRs). The demonstrator will not be a production system however,
it will be implemented within a real-life repository environment at KCL, and the implementation will address genuine needs, in particular by reducing the need for manual intervention and providing a more streamlined deposit process.

Name of Trawler:Mahendra Mahey

Output:No Outputs available as yet
Suggested outputs might include:

  • Detailed scenarios and use cases for enhanced ingest
  • Examination of services and tools that may be used to support this functionality
  • Create a demonstrator integrating these services to implement the identified workflows
  • Evaluate the results of the project, and in particular the extent to which the available services and tools, and associated standards, support the requirements

Specific deliverables:

  • demonstrator system
  • case study
  • shorter report co-authored with the CRIG Support Team
  • e-Framework components, including detailed scenarios, SUMs, Service Expressions

Project – FAR

Federated Access to Repositories

Project Name: Federated Access to Repositories

Programme Name: Digital Repositories programme

Strand: Interoperability Demonstrators

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/programme_rep_pres/interoperabilitydemos/far.aspx

Project URI:https://gabriel.lse.ac.uk/twiki/bin/view/Projects/FAR/WebHome

Start Date:01/11/2007

End Date:31/07/2008

Governance: Integrated Information Environment Committee (JIIE)

Contact Name and Role: John Paschoud, Project Manager

Brief project description: A workshop at the OAI5 conference in April 2007 identified a need for improved attribute managed federated access to repositories, and produced a set of requirements. The Federated Access to Repositories (FAR);project would take up this list, and use it to: Create recommendations for attributes to describe authorisation to repositories; where appropriate,;these recommendations will be passed to relevant standards groups Develop extensions to the repository software (EPrints and DSpace) so that it can be used with; Shibboleth and meet these requirements (building on earlier work where this exists) ;Test existing work integrating Shibboleth and Fedora and recommend to developers what will be;needed to meet these requirements ;Install demonstration repositories to show how this can work in practice Feed the modifications and full documentation into the appropriate repository software development process to ensure maintenance through future releases of Eprints and Shibboleth Develop procedures to consider ways of extending federated access management to new functionality introduced into the repository software products following the conclusion of the project A demonstrator of the software will be produced as well as a final version.

Name of Trawler: Mahendra Mahey


Project – The Depot

Project Name: The Depot

Programme Name: Repositories and Preservation Programme

Strand: Information Environment

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/reppres/depot

Project URI: http://depot.edina.ac.uk/

Start Date: 1st August 2006

End Date: 31st March 2009

Governance: RPAG

Contact Name and Role: Bill Hubbard, Project Manager

Brief project description:

“The Depot is a JISC support service, launched in June 2007 with the specific task of ensuring that all in the UK research community can benefit from making their published papers available under Open Access, and helping maximise readership of their work. The Depot is OAI-compliant, allowing deposited e-prints to be ‘harvested’ by search engines across the world.”

The Depot offers two services:

  1. a re-direct service, with the Depot acting as a gateway, especially to repositories at UK universities (institutional repositories)
  2. a deposit service for e-prints, with the Depot acting as a national repository for researchers not yet having an institutional repository in which to deposit their papers, articles, and book chapters (e-prints).


Project – The Deposit Plait

Project Name: The Deposit Plait

Programme Name: Repositories and Preservation Programme

Strand: Information Environment

JISC Project URI: http://www.jisc.ac.uk/whatwedo/programmes/reppres/interoperabilitydemos/depositplait.aspx

Project URI: [None that I can find other than http://cadair.aber.ac.uk/dspace/handle/2160/582]

Start Date: 1st May 2008

End Date: 31st Dec 2008

Governance: RPAG

Contact Name and Role: Stuart Lewis, Project Manager

Brief project description:

“The 5 elements of the project aim to investigate:

  • Metadata requirements of repositories and service providers of deposited items
  • What metadata can be easily extracted from the deposited document, and if useful, whether a web service can be built to provide such metadata from a file
  • What metadata can be obtained from online metadata sources and personal bibliographic management software
  • Possibility of building a ‘Meta-API’ using the open document format web service and bibliographic data sources
  • What metadata needs to be verified or provided by the depositor

The initial element of the project will document the metadata needs of repositories and service providers (e.g. Intute Repository Search, OAIster, Google Scholar) from a deposit engine. Following that, three strands of a potential plait of data providers will be investigated to see which can provide each of the metadata needs identified. The investigations will focus on what systems and software could provide this information, what interfaces there are into these systems, what interfaces would be useful, and what services could be built upon the interfaces. The findings will be written up in a final report.”


Four reports –

  • Report 1: A report into the metadata requirements for repositories and service providers, aimed at facilitating the evaluation of the other work packages.
  • Report 2: A report detailing the findings of the investigation into metadata that is available from information stores.
  • Report 3: A report detailing the findings of the investigation into metadata that can be derived from a document.
  • Final report: A report pulling together the contents of the first three reports, and subsequent investigations into the possibility of a meta-API.

Outputs will not available until early 2009.