1
|
- Geoff Payne,
- ARROW Project Manager
- Andrew Treloar,
- ARROW Technical Architect
|
2
|
- 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
|
|
4
|
- 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
|
- 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
|
|
7
|
|
8
|
- 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
|
- 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
|
|
11
|
- 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
|
|
13
|
|
14
|
- 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
|
|
16
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- Details of the ARROW project can be found at:
- arrow.edu.au
|