Software choices for Metadata Stores projects

In the October Metadata Stores Newsletter #9 there was a call for your rationales for choosing Metadata Stores software. The following rationales have been provided for sharing. If you have not already done so and would like to share yours, then please email a paragraph to be added to this (unordered) list:

University of Adelaide: The two candidate Metadata Store Solutions originating from academic institutions are very different in nature. ReDBox is an Australian developed Metadata Store focused on curating metadata within an institution. VIVO, originating from Cornell University, is much wider in scope aiming to use Semantic Web functionality to provide an overarching discovery and network building tool for researchers across institutions.

The comparative review examined the attributes of each system in terms of functionality, vendor capability, service and support, vision and cost. This document summaries that comparative review.

In general ReDBox can be considered to be a much smaller system in comparison to VIVO in terms of scope, complexity and vision. This lighter weight system is better focused on the needs of the University of Adelaide’s Research Metadata Store Project, with key advantages in the areas of complexity, workflow implementation and support. ReDBox overall represents a better fit for the needs of the Research Metadata Store Project - (Evaluation document attached).

The University of South Australia has evaluated a number of open source software solutions as part of the Research Metadata Store project. In order to ensure that UniSA has an enterprise-wide Research Metadata Store solution that not only meets our deliverables for the ANDS project but also fulfils the need for an overall metadata store solution, the Project Team has documented the complete set of ANDS requirements in addition to capturing all the UniSA requirements for a research metadata store then compared each open source software solution against the combined ANDS and UniSA requirements - (Evaluation document attached).

University of Queensland is developing custom software for its metadata store. Existing software that was available at the time did not complement other systems at the university and required non-trivial customisation to integrate. A custom approach gave the project more control over what functionality is available, how it is implemented and the timeline for delivery -- which was important for reducing the project risk, since many aspects of the project had never been done before. The approach requires more development resources, but it is expected the investment will result in a solution that is better aligned and evolves with the diverse and changing needs of the university.

University of Western Australia: UWA chose VIVO for its ANDS Metadata Store for several reasons: its potential to develop into a full ‘Research Profiles’ system, its use of Linked Data / Semantic Web technology, and the availability of Australian expertise at Melbourne, Griffith and QUT. We chose not to use an integrated repository/metadata store system like ReDBox, largely because we were already using a commercial product (DigiTool) for our publications repository. DigiTool itself was not suitable as an ANDS metadata store, and building an ANDS metadata store directly on to DigiTool was not an option.

The Australian National University’s reasoning for the adoption of Vivo is a little more complex than it first appears.

Our abstracted high level architecture is in appendix 2 of our project management plan and our choice of orca revolves around our need to have a store of some sort in our implementation. We have looked at a number of solutions

1) virtualising the store, i.e. pulling the data in real time from the various sources and building a display tool
2) using vivo as the display tool and simply pulling the data from a variety of sources and caching it in vivo
3) using orca as a backing store for data

We've come to the conclusion that a purely virtual store is not practical which means we need an interim store if only to store newly minted NLA party identifiers.
As we were already planning to use orca as a standalone collections registry populated from our data capture and seeding the commons projects it made sense to extend the use of orca rather than have another database.

Vivo we discounted because of its implicit organisational model - we did have it running with a very sparse set of data harvested from a number of sources, but we felt it was very person centric as opposed to research output centric
However our use of orca is pragmatic and designed to save us development time - there is no reason in our architecture why it could not be replaced by something else that did the job, and because we are using a very agile methodology we may yet do so should orca have performance problems.

It's our intention to then build a front end that gives a number of views and to see the core system effectively as middleware that supports a range of standard queries.
In that way the metadata store could be used as a source to populate individual research school's web pages in a standard manner to get a consistent view (and presentation) of the information across the institution.

University of New South Wales reviewed ReDBox, Vivo, MyTARDIS and the in house ResData. The evaluation was detailed and the conclusion was that the existing system ResData could be extended to include the required functionality and combined with Mint. However the other systems would require significant work to integrate with the existing systems.

Researcher participation: a clever strategy from UWS

At the Metadata Stores roundtable in Sydney on the 31st August 2012, Susan Robbins (University of Western Sydney) outlined a clever strategy for getting researcher participation. Susan has kindly agreed to share:

'Our Research office selected about 30 key UWS researchers, from a range of subject areas, who had recently completed ARC or NHMRC grants (with possible data). To the spreadsheet, they added grant details and attached an associated publication. They sent this to me for information and to our DVC Research. The DVC emailed the researchers outlining the project, reasons why they should participate (and strongly urged them to do so) and said I would be in touch to discuss details.

I emailed the researchers the next day with some more information, including the specific grants identified by the Research Office and attaching the publication. About half the researchers emailed me back within a few days. About half of the rest had out of office messages and most have since been in touch and the rest didn’t ever respond. I made appointments to ring or visit the respondents (with a colleague) to discuss the project in more detail and what their participation would involve. Every single one agreed to participate.

The Library has access to a lot of the information required for the questionnaire, so we pre-populated it as much as possible. It was then emailed back to the researcher with the option to either complete and return or ring us to fill in the missing information. Most chose to do it themselves and send it back to us. There was usually a couple of emails/calls back and forth. This proved a popular way to participate as it meant less disruption for the researcher.'

Thank you Susan. If you need more details, you can contact her at: S.ROBBINS@uws.edu.a

Project Governance - roles and responsibilities

To date, in the Metadata Stores Program, 11 Universities have established Project Steering Committees or Project Management Groups. Some of these groups meet monthly, some quarterly. Some are formally constituted with Terms of Reference (TOR). Some have ANDS representatives on them and some will continue on after the ANDS project completion date.

For those of you still working towards some form of Project Governance, the following outline of the various roles and responsibilities is intended to help.

Ideal structure

Roles and responsibilities

• Responsible for the Steering Committee
  
  • Sets terms of reference
  • Provides direction and guidance
  • Sets priorities
  • Sets funding level
  • Sets timeline
  • Sets deliverables
  • Appoints chair person
  • Provides resources
• Promotes the project work to VC colleagues and subordinates

Steering Committee or Project Board

• Provides reports, advice and feedback to DVCR and other senior members of the university
• Owns terms of reference
• Monitors expenditure of funds
• Reviews management of project risk
• Ensures reports are regularly submitted to higher bodies and DVCR
• Offer professional advice and support
• Promotes the project work to colleagues and subordinates
• Recruits subordinates to assist project work
• Supports Project Manager
• Provides resources
• Provides support
• Provides feedback
• Provides guidance, direction and assistance [including direction on how to respond to events or constraints that are outside the control of the project]
• Reviews project progress
• Reviews each completed phase and approves progress to the next phase

Key behaviours

Generally, the Committee or Board manage by exception. This ensures that all members of the board are given equal opportunity to participate in Board level decision making processes and feedback from all members is actively solicited Project Board members do not regularly delegate attendance at meetings.

Steering committee/Project board roles

Chair / Executive

The Chair ultimately is responsible for the project, supported by the other board members.They ensure that the project is focused on achieving its objectives and delivering deliverables and outcomes that will achieve the projected benefits. The Project Chair will...

• Be the decision maker with overall authority for implementing the Project Plan
• Ensure that there is a coherent project organisational structure and a logical set of plans to deliver the project deliverables
• Ensure that risks are being tracked and mitigated as effectively as possible

Other members

Represents the interests of their departments to all researchers who will be involved in the project.

Have authority to resolve project requirements and priority conflicts.

Ensure that appropriate quality control procedures are used to ensure the project meets ANDS and the universities own requirements.

Project Manager

• Responsible to the Steering Committee
• Promotes the project work to colleagues and subordinates
• Responsible for day to day work of the project
• Works with colleagues to deliver project outputs

Metadata Stores: Acceptance criteria for required deliverables

Principles:

• ANDS requires a Project Plan early in the project, in order to finalise project scope, choice of software and to confirm appropriate resourcing and planning;
• If a project is embarking on metadata stores without existing infrastructure, then ANDS will not require delivery of the complete metadata store, nor all the deliverables depending on it - until the end of the project.
• If a project is embarking on metadata stores with existing infrastructure, then ANDS expects that there will be a feed of records supplied to RDA (see Deliverable #1) by the middle of the project.
• Remaining mandated deliverables are likely to have multiple dependencies on other software and organisation units, so ANDS will not require delivery until the end of the project.
• ANDS encourages project to schedule deliverables earlier than agreed in the project description where possible.
• Because there is likely to be a lengthy period between the Project Plan and other deliverables, ANDS requires regular and frequent progress reporting - every three months. Reporting will be lightweight, just a couple of pages, but ANDS needs to monitor progress closely, given that these are infrastructure projects with a large number of dependencies.
• For consistency, ANDS is maintaining a ratio of payments across all projects of 25% each payment period.

D1	A working feed of records describing Collections and associated Activities, Parties and Services to Research Data Australia, in the current version of RIF-CS (1.3), demonstrated to meet the quality requirements for RIF-CS records as set by ANDS. Acceptance: If the project is using an existing technology* then this feed is expected around the middle of the project. The feed will be confirmed by an inspection (by CLO*) of a sample of nominated records in Research Data Australia. If the technology is bespoke then an expected date should be included in the Project Plan.  *Existing technology means that there is already a working Metadata Store. *CLO = Client Liaison Officer (ANDS.
D2	A feed of collections from at least three distinct Faculties (or equivalent organisational units) within the institution to Research Data Australia.  Acceptance:  This spread across Faculties is intended to support an institution-wide approach. The feed can be automated or manual.  The 3, or more, Faculties (or equivalent) will be confirmed by an inspection (by CLO) of a sample of nominated records in Research Data Australia.  An expected date should be included in the Project Plan.
D3	Demonstrated alignment of metadata records about Parties with an institutional name authority (HR or Library), with the authoritative form of the name sourced external to the metadata store, and with new researcher descriptions added to the metadata through regular updates from the name authority. Acceptance: This interface between one or more nominated sources of party record details and the Metadata Store is expected to be confirmed by a statement of achievement by Project Manager.  Specifically, this will be demonstrated by an alignment of metadata records about parties with an institutional name authority (HR or Library), with the authoritative form of the name sourced external to the metadata store as well as new researcher descriptions added to the metadata through regular update from the name authority be confirmed by written statement by project partner. An expected date should be included in the Project Plan.
D4	Demonstrated alignment of metadata records about Parties with the ARDC Party Infrastructure Project, with researcher descriptions contributed to the NLA, and with People Australia identifiers for researchers recorded against researchers. Acceptance:  Alignment with the NLA Party Infrastructure will be demonstrated by an inspection (by CLO) of examples of records using NLA Identifiers in Research Data Australia, as nominated by Project Manager.  An expected date should be included in the Project Plan.
D5	Demonstrated alignment of metadata records about Activities with institutional and external sources of truth (Research Office, ARC and NHMRC grant registries), with the authoritative description of the Activity sourced external to the metadata store, and with new researcher project added to the metadata through regular updates from the sources of truth. Acceptance:   Integration with the ANDS records derived from the Grants Registries will be demonstrated by inspection (by CLO) of nominated examples of Activity records.  An expected date should be included in the Project Plan. See updated criteria for this Deliverable
D6	Demonstrated workflow for registering new Collections in the university; this can include automated update, or semi-automated (notification-based). Acceptance:    This will be demonstrated by a document description (with schematic) of the workflow that includes some form of alert or notification that a new collection has been, is being, or is about to be, created. An expected date should be included in the Project Plan.
D7	A software system to realise deliverables D1–D6 (and D8, D13–D14 if applicable), with robust storage and management of metadata. Acceptance:  ANDS does not intend to assess software code already assessed or approved e.g. ReDBox, VIVO. A detailed diagram(s) of the working metadata store with associated use-case(s) will be used to assess the deployment by the ANDS Technical Assessment Group and will be shared with ANDS partners  (note - please insure that these diagrams are licensed as CC BY).
D8-D13	Optional Deliverables Acceptance:  ANDS expects each institution to choose at least one optional deliverable. Progress of chosen optional Deliverables is expected to be included in the ANDS Progress Report Template.