The ELAR Metadata Set David Evans, ELAR 3 November 2006

XML and Databases  Archive object metadata will be stored on a MySQL database.  This is flexible, but unfriendly!  Using XML as an interchange format lets us both:  Validate incoming deposit metadata against a schema; and  Transform outgoing archive object metadata for different audiences and purposes.

Metadata Issues  Which metadata to include?  This question had already been answered – by our own Deposit Form!  Inspiration drawn from METS  Deposit Form metadata divided into Admin., Descriptive, Technical and Preservation Sections  File Sections and Groups  Multiple structural maps

A Hierarchy of Metadata  Sections of metadata can be applied to :  Deposits;  Files; and  Fragments.  MD defined higher in the hierarchy filters down.  Most MD elements can be applied to any of these ‘containers’. We also define a Bundle as a fourth metadata container, and an arbitrary collection of archive objects.

Interoperability  Mappings / crosswalks to other MD formats will be achieved via XSL stylesheets.  Harvesting can be handled on the fly, issuing resumption tokens if necessary.  MD for files or fragments can be created for export by including inherited values from higher levels of the hierarchy.

Access Protocols  From the ELAR Deposit Form, access permissions are expressed in a series of codes.  Viewing or download privileges can be given to:  Everyone;  No-one;  Named individuals;  Members of research and/or language communities.  Depositors can choose to be notified of each request, or let ELAR decide who gets access.

User Groups  The owner of a resource (i.e., the depositor) decides which groups are allowed access.  Users of the website can see which groups have access, and may apply to join as many of those groups as they like.  Conditions for approving or denying membership can be stipulated by the depositor.  Groups may exist independently of resources.

A Scenario: Applying For Access DepositorCommunity Member 1. Declare permissions 5. Notification of claim 6. Decide on permissions 2. Ask to view resource 3. Demand membership 4. Claim membership 7. Access granted (?) Interface (possible shortcut)

Better Metadata, A Better Website  ELAR shares the login system with MyHRELP. At present, this enables:  Depositors to modify their deposits’ metadata; and  ELAR staff to execute various admin functions.  At present, there’s no benefit for anyone else. But could there be?  A combination of registered users, arbitrary bundles and fine-grained access permissions offers some possibilities.

Personalisation  Registered users could create their own bundles of resources, making these available to others in turn. For example:  ‘Videos from Siberia’  ‘Conversations about Religion from the Philippines’  Collaborative metadata editing  New types of metadata?  ‘Re-use’ or ‘Re-purposing’ protocols?  Permissions to add or change metadata values?

Comments on the presentation  Daan Broeder: “Past versions of updated metadata should still be available for search and retrieval”  Ed Garrett: “Could depositors restricting access to resources lead to legal problems?”  David Nathan: “This should be covered in the agreement signed on the Deposit Form”.