Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

2019-2010 Work Plan Tasks and Goal

  1. Defining our level of commitment to various library and archives standards
TaskNotesTimeline/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

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.


Determine what belongs in which tier

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

Next 2nd 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?

    to be re-evaluated once Agent module work is done), OAI-PMH


    Support for Emerging Standards

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


    ...

    TaskNotesTimeline/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

    TaskNotesTimeline/Assignment
    Review existing tooltips for DACS compliance
    To be reviewed at Nov meeting
    Look at new DACS fields or suggestions

    Jira Legacy
    serverSystem JIRA
    serverId36c489e2-4fb0-353a-985b-64038401be2f
    keyANW-883

    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

    ...