1	‘State of the ARROW’ DLF presentation 25 October 2004 Geoff Payne, ARROW Project Manager Andrew Treloar, ARROW Technical Architect
2	ARROW Acronyms Australian Research Repositories Online to the World (ARROW) is a Federated Repositories of Digital Objects (FRODO) Project funded by the Australian Commonwealth Government Dept of Education, Science and Training (DEST) DEST Funding of A$3.66M over three years (2004-2006) ARROW Consortium Partners Monash University (Lead Institution) University of New South Wales Swinburne University of Technology National Library of Australia
3	ARROW – original high level architecture
4	ARROW Technology – Software Need a repository system early in the project To learn what works and what does not work To manage content as a demonstration system But all Repository software is immature at present Commitment to open source software in the ARROW Funding Agreement Evaluation of DSpace, Fedora, other software
5	ARROW Technology – Software Selected Flexible Extensible Digital Object Repository Architecture -Fedora™ Software by Cornell University and University of Virginia VITAL from VTLS Inc www.vtls.com as development partners ARROW / VTLS partnership to take the Fedora “engine” and construct a working repository to meet ARROW’s functional requirements Sustainability through vendor support
6	Resulting VITAL Application Stack
7	ARROW model – components selected
8	Fedora™ - Flexibility at the expense of implementation design effort Allows storage of any number of different types of digital objects But extra effort required Data Modelling How any given type of digital object will be stored can be tailored to suit Metadata schemata for each data model (or even every object!) are allowed Persistent Identifiers flexible
9	ARROW - Data modelling Required to define how objects will be stored Atomic objects Level at which an individual Persistent identifier must be applied to allow reference as part of multiple complex objects Functional Requirements for Bibliographic Records (FRBR) as guidance on atomicity Atomicity at the FRBR expression level
10	Inside ARROW…
11	Metadata Requires metadata schemata to suit individual data models No requirement to shoehorn all metadata into one schema Each stored object can retain metadata developed for it by the community of practice which generated the object Maintains flexibility to store many types of digital objects in the repository No need to anticipate every object type now
12	OCLC Metadata Interoperability Core
13	Data Models
14	Persistent Identifiers Proposed ARROW Handles Format http://arrow.monash.edu.au/hdl/xxxx/yyyy xxxx = ARROW handles naming authority nnnn.n – one sub number for each ARROW repository yyyy – running number
15	ARROW Branded Services Profile
16	ARROW Project Teams Technology ARROW Technical Committee Establishing a vehicle for content management Content (=Advocacy) ARROW Content Committee Cultural changes to ensure content capture Project Management ARROW Management Committee
17	ARROW stages Demonstration (2004) Developing architecture, selecting, testing and developing software Deployment (late 2004 – end 2005) Populating the ARROW Partners’ repositories Distribution (mid 2005 – end 2006) Enabling others to participate Under review for earlier participation by others
18	ARROW Software Development – Stage 1 August 2004 - Installed Vital 1.0 UNSW and Monash Functionality Image Management Fedora native ingest for other digital objects Dublin Core metadata Training based on Test Server at Monash 2 Production Servers, 1 Test Server
19	ARROW Software Development - Stage 2 October 2004 - Install Vital 1.2 NLA and Swinburne, upgrade at Monash & UNSW Functionality Image Management – additional image types Text Documents Fedora native ingest for other digital objects Training based on Test Server at Monash 4 Production Servers, 1 Test server
20	ARROW Software Development - Stage 3 February 2005 - Install Vital 2.0 Upgrade for Monash, UNSW, NLA and Swinburne Functionality - Manage Audio Manage Video Fedora native ingest for other digital objects Training based on Test Server at Monash 4 Production Servers, 1 Test Server
21	ARROW - Summary of design criteria A generalised institutional repository solution Initial focus on managing and exposing traditional bibliographic research outputs Expand to managing non-bibliographic research outputs Design decisions are being taken with the intention of not precluding management of other digital objects such as learning objects and large research data sets
22	ARROW Content (Advocacy) Advocacy tools prepared and circulated Pro Forma Memorandum of Understanding with a university faculty of department Copyright strategy paper drafted ARROW Frequently Asked Questions Pursuing policy changes such as mandatory deposit of e-Theses Project champions recruited
23	ARROW Content (Continued) Design work proceeding on an interface between Research Master (RM) and ARROW for gathering DEST research evidence Monash, Swinburne, UNSW all use RM v.4, but the solution will be as generalised to accommodate other practices Administrative efficiency gains DEST incentives to deposit are mooted Migration of content from e-prints repositories planned
24	ARROW partnerships Established VTLS Fedora Thomson ISI Web Citation Index Prospective OCLC, to test the metadata interoperability core Google, to test indexing of research materials Open Journal System, to enhance the OJS Software
25	ARROW FRODO Partnerships MAMS – Meta Access Management System Access control through eXtensible Access Control Markup Language (XACML) metadata Needs development of a FRODO profile of XACML for access control interoperability APSR – Australian Partnerships for Sustainable Repositories Interoperability through consistent metadata for similar data objects Needs FRODO Metadata schemata for object exchange, export and ingest into new repository environments as part of sustainability and preservation initiatives ADT – Australian Digital Theses Interoperability through harvestable Dublin Core metadata Supporting e-theses online which are pointed to from ADT Role for an overarching Web services strategy?
26	Authentication, Authorisation, Rights Management MAMS Project is working in this area Shibboleth as a model XACML as a way of encoding fine grained access control Digital Rights Expression Languages and Patents Repositories need access control to honour constraints imposed by copyright owners eg to meet the ROMEO database expressions of publishers permissions policies for depositing previously published content to repositories
27	Further information Details of the ARROW project can be found at: arrow.edu.au