...
Item |
|---|
Introductions (Ice Breaker Question: What was your first car? If you've never had a car, your first bike?) |
Reviewing the Work Plan |
Scheduling Future Meetings |
Action items
Notes
Monthly TAC Meeting
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
This subteam is scheduled to report on our activity for the 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 levels 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, and we should undoubtedly support these
Supporting 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 can be exported
Should we be deeply involved in this?
Christine: For
...
ArchivesSpace right now, testing this feature won’t be available
...
for at least
...
one 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:Defining the First Tier of Support
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
Defining the Second Tier :of Support
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 We are to review these tier definitions at the next call, and finalize it thenthem
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 a priority for this also
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 withinhttps://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 Christine about API access on the sandbox as well
Universal Export Record Testing
Want more than one
...
possible set of field values 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 Goals for Next Time
We will need to draft a separate work plan task to encompass and assign the following mapping evaluation steps:3.
Dividing up elements to check
...
Check fields that can be easily checked
...
Isolating import fields that are more challenging to check
Publishing the Results of the Evaluation for the Metadata Mapping
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 the TS-DACS council
Reviewing metadata-related development tickets
Maggie and Lydia created a new JIRA issue 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 PointScheduling Future Meetings
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