2019-2010 Work Plan Tasks and Goal
...
| Task | Notes | Timeline/Assignment |
|---|---|---|
Tier definitions | 1st tier: ArchivesSpace strives for an optimal support of standard. For structural standards, import and export. (NB This is not 2nd tier: ArchivesSpace strives for compliant support. For structural standards, export. | Agreed, 10/17/19; can be revisited as we work through mappings |
| Determine what belongs in which tier | 1st tier: EAD2002, MARC, and DACS 2nd tier: Dublin Core, EAD3, EAC-CPF (to be re-evaluated once Agent module work is done), OAI-PMH | Agreed, 10/17/19; can be revisited as we work through mappings |
| Support for Emerging Standards | Monitoring standards changes, and commenting on behalf of AS community as warranted, e.g. RiC | As needed |
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 |
(in rough priority order) |
|
|
Which mapping to update / who / how
| Done |
Getting some sample imports and exports |
Kevin - MARC (done) Jared - EAD (done) Should be ongoing as we identify testing needs | ||
| Find workspace to store records | Completed - James and Christine created repos for us to use | |
| Determine test process for import | 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 Google Sheet for tracking review: https://docs.google.com/spreadsheets/d/1jU6MYF7UI7a-UKdd5XhYCV6W1UyrMMCzYDFlgb8iNW8/edit?usp=sharing | |
| Determine test process for export | Create a sample record (records?) with every field filled out, with the content being the fields name. Make sure we cover expected cases (dates, extents) that might need multiples of repeated fields. | |
| 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
| |
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 |
Ticket about new DACS rights field? |
34. 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
45. Offer a mechanism to provide feedback
...