Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

Date and Time

01:00PDT/04:00 EDT - 02:00PDT/05:00 EDT

Zoom URL

https://lyrasis.zoom.us/j/897871318

Participants

Goals

Discussion topics

Item

Introductions (Ice Breaker Question: What was your first car? If you've never had a car, your first bike?)

Reviewing the Work Plan

Action items

  •  

Notes

Updated the TAC team on the outline of the work plan earlier in the week

We will proceed with reviewing and finalizing the work plan during this meeting

Scheduled for December TAC Call

Work Plan

Need to break these down into smaller tasks, and have people volunteer to take on this work

First item: Defining level of commitment to various standards

Key is to determine what this actually mean

ASpace exports MARC records

But a functional MARC record can still be fairly skeletal in content

EAD2002, DACS, and MARC are the core standards

Emerging standards

What do we think the second and third tiers look like?

EAC-CPF with agents and revision improvements will increase the support to ensure that more than minimal records

Should we be deeply involved in this?

Christine: For the application right now, this won’t be available for testing for at least 1 month

Mapping:

Once we have a workflow for getting through the different mappings, we can return to the mappings for EAC-CPF after agent/revisions have been addressed

First Tier:

Perhaps the ability to both import and export could define this?

Any first tier metadata standard shouldn’t just be functional, but optimal

EAD3 is functional, but not all of the tags are used fully

Cannot import and export DACS in ArchivesSpace

For structural metadata, the first tier should still be import and export

If this turns out not to be a possible goal, then review this and we loosen the definition of first tier

Second Tier:

Any sort of basic compliance with exports (such as exporting EAD3 records which are valid)

The records here will be much more minimal

We might want to specify that these are archival or library cataloging standards, not broader technical standard (e. g. JSON exports of data)

Review this at the next call, and finalize it then

Published Metadata Mappings

This Subteam cannot complete this entirely

Updating the published mappings and maintaining them better over time with each ASpace release or update to metadata standards

Existing Mappings

To what extent does our charge include those standards which are specific to libraries and archives?

Prioritize what is specific to archival standards

EAC-CPF export should be considered

Methodology for Evaluating Mapping

Try and have a summary which indicates where the mappings are implemented in the code base

Sample imports and exports: work toward a set of records?

James will contact Christine request a repository on GitHub within https://github.com/archivesspace

Find 3-4 sample MARC and EAD records which are wide-ranging for testing import and export features for the next meeting

Do we want a JSON resource record also to serve as a standard for checking imports?

In Archivist’s Toolkit, test stylesheet by filling all possible fields

Perhaps something similar could be used to test export compliance

We will just be using the sandbox ArchivesSpace installation for the resource record

James will ask about API access on the sandbox as well

Universal Export Record Testing

Want more than one possibility to be tested

Attach multiple dates, ranges, multiple extents

Want to ensure that various types of field values are tested

Testing Importing Records

Unreasonable to ask everyone to submit one?

Do we want just 2-3?

Someone had a repository of strange EADs

We to at least document that we don’t import certain elements

Should keep this scoped fairly reasonably

Kevin can volunteer for MARCXML records

Pulling together sample EAD records: Jared will look for UC Davis

Article: Double Shoehorn Article from Harvard

Analysis of what worked and what did not

Next Step

How are we going to check that the import/export behavior is what we expect it to be?

We need to be able to document and sustain this

We could try round-tripping records, or just have this as a task

Task: Determine what process do we need to use to test this

Goal for Next Time:

3. Dividing up elements to check

4. Check fields that can be easily checked

5. Isolating import fields that are more challenging to check

We don’t have a task for publishing the mappings

We need to determine how to publish these

Question for core committers group: How to synchronize this with the development reviews

Greg will bring this up during the next core committer group meeting

DACS import support

To the extent that new DACS fields are added, we will need to track the decisions of council

Reviewing metadata-related development tickets

Maggie and Lydia created a new label

Standing item: We will review tickets every call

Mechanism for feedback

Table this for the moment, while the mapping work becomes the highest priority

Administrative Point

Kevin will send around a Doodle Poll for a monthly meeting time

We can also just have a rotating, standing meeting

Meeting adjourned at 13:50 PDT/16:50 EDT

  • No labels