DAMS Project

A meeting from the DAMS team made me generate these notes. The project is ambitious and has many points to be a successful one. I’m still not fully involved in the project and I hope that this will happen soon.

The project and services pages is at http://damssupport.ouls.ox.ac.uk/trac and more specific about the DAMS project can be also seen in this page.

The trac system is used, which is equivalent to a wiki, allows attaching files, code sub-vsn, tickets (bug tracking), roadmap (milestones), etc. It is also an event management system and is unique place to all projects.

Why use the trac system?

  • JISC accepts blogs and wikis as documentation
  • has RSS feeds for timeline changes
  • XSLT >> reports
  • backend is in Python, currently in VMWare

Vocabulary used as standard and created by projects will be at http://vocab.ouls.ox.ac.uk/

Event-message system

The filesystem has the structure:

Storage-messaging-index

JMS – Java messaging system, queue with msgs (stack)

AMQP – email msg type

RabbitMQ (silent: success, noise: fail) – indexes, specify in advance a queue

Fedora – 2 queues:  API-M and API-A (CRUD – create, read, update, delete)

Why DAMS?

  • digitisation
  • Store “things” and metadata about them, independent of Fedora
  • components, open interfaces, open standards

Scalability

  • object storage, cluster / distributed system, live replicas
  • MAD (idle disks)
  • Honeycombe (self-healing system)
  • search engines (indexing accessing)

Longevity

  • simplicity interfaces
  • reduce dependency of third-parties
  • abstraction layers/resolvers

Availability

  • enhance long-term availability
  • disaster-recovery
  • snapshot of VMs on the system
  • digital preservation
  • represent the entire collection

Interoperability

  • implementation of interfaces
  • avoid low-level interfaces (use standard interfaces)

Sustainability

  • budget, archival, migrate skills
  • from analogue to digital culture

DAMS Phase 2

Skills needed for the future and the current projects.

Honeycombe – write once read many. Make amends, difference and commit later.

Check also: Less talk, more code blog at oxfordrepo.blogspot.com