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

BRII Meeting (1)

Idea: get a significant amount of data from the different university departments/colleges in a sort of collaboration. Mostly profiles of researches and areas of interest to make available and searcheable for future use withing the university (and outside).

Meeting with departments/key people was determined to be only 30 minutes; more will be too long, less would be too short.

Comlab accepted to collaborate with the project and could also be a bridge between Baby lab and linguistics group.

Another project with similar concepts is the Core User Directory where not only profiles will be gathered but also the different affiliations of each person.

A quick discussion about which survey tool could be used for gathering some information when a one-to-one meeting is not possible took place, and Google forms was raised, but Survey monkey had more features and was easier to control (and add security) so was chosen for a test.

A few items were also mentioned as:

  • creating templates for briefings
  • use of openID
  • RESTful template/interface (bluepages?)
  • mindmap
  • BRII blog
  • Sharepoint
  • trac

The ideal situation on getting the data is to get ‘live’ data instead of static. So once one piece of information is updated the data on the system will reflect the changes.