2019-2020 Metadata Standards sub-team Work Plan

2019-2010 Work Plan Tasks and Goal

Task

Notes

Timeline/Assignment

What does this mean in practice?

E.g., 1st tier is import and export; 2nd tier only export, or we might just offer the mapping.

Determine what belongs in which tier

First tier of compliance and documentation: EAD2002, MARC, and DACS

Next tier: Dublin Core, EAD3, EAC-CPF (?), OAI-PMH

EAC-CPF seems to be pretty closely bound to the RDF, and I'm uncertain as to how importing this could be readily supported without flattening the graph (which is possible, just a feature request, I would assume).
OAI-PMH, from what I could determine, builds heavily upon Dublin Core (http://www.openarchives.org/OAI/openarchivesprotocol.html#dublincore), so this might be interchangeable with Dublin Core support for certain cases
EAD3 and Dublin Core are just XML - perhaps XML-based standards constitute a higher tier of support than non-XML?

Support for Emerging Standards

Monitoring standards changes, and commenting on behalf of AS community as warranted, e.g. RiC

2. Maintaining published metadata mappings

(this will need to be broken down into tasks, and we will need to ensure that we clearly define our level of commitment)

Task	Notes	Timeline/Assignment
List existing mappings	Accession CSV Import Digital Object CSV Import Digital Objects MODS Export Digital Objects METS Export Digital Objects DC Export EAD 2002 Import EAD 2002 Export EAD3 Export MARCXML Import (Q: Are resource, accession, agent imports mapped differently?) MARCXML Export OAI-PMH MODS OAI-PMH DC OAI-PMH DCTerms EAC-CPF export
Which mapping to update / who / how	1. Getting some sample imports and exports in a workspace 2. Set up some sort of process to document checks. 3. Dividing up elements to check 4. Check fields that can be easily checked a. We should be able to check a lot of the exports in sandbox.archivesspace.org 5. Isolating import fields that are more challenging to check a. (I’m thinking some of the more long tail things, with <colspec> or odd <fontmatter> elements to check how that imports) b. I did not know that <ptrloc> was a thing, for example (https://www.loc.gov/ead/tglib/elements/ptrloc.html) 6. Finding/creating records to test with long-tail elements
Ensuring that code changes impacting metadata mappings are communicated would be a great contribution	Instructions to community members in how to create JIRA tickets for review Questions/Comments Is there any point of intersection with labors of the Development Prioritization subteam? Specifically the development roadmap?

3. How DACS integration is supported and how tooltips are in sync

Task	Notes	Timeline/Assignment
Review existing tooltips for DACS compliance		To be reviewed at Nov meeting
Look at new DACS fields or suggestions	ANW-883 - Getting issue details... STATUS Ticket about new DACS rights field?

3. Reviewing metadata-related dev. tickets and to what extent a request to improve a feature will be rewarding to the community

→ To be a standing agenda item; 10 min of every monthly call for review, discussion, and if necessary a volunteer to draft a comment

4. Offer a mechanism to provide feedback

During the TAC Monthly Meeting for October 15th, Kevin proposed that the mechanism for capturing feedback may be to use JIRA in coordination with monitoring the listserv
Other attendees seemed responsive to this, but there was equal interest in integrating Confluence with listserv activity, or, perhaps, creating additional listservs

Ideas and Tasks For the Future