...
Migration is often heavily informed by ensuring that the imported metadata follows standardized schema
How can we make explicit what ArchivesSpace commits to in terms of metadata standards?
How do we document this?
Daniel: A lot of this works came out of the structure of the EAD
There is a desire to ensure that EAC-CPF and MARC exports are fully supported from within ASpace
Tooltips for the system are based on DACS, but this is customizable
Resource record section is based on EAD and DACS
Internationalization
We should note that RAD or ISAD might be preferred by adopters outside of the United States
Hence, DACS might not be preferred for those outside of the US
OAI-PMH Implementation
Note that this supports Dublin Core
There are tiers of support for standards when it comes to adherence
For some standards, ASpace just exports data with the bare minimum level of compliance
This should be distinguished
Highest level of compliance and documentation should be there for MARC, but for cases such as Dublin Core, we might just offer the mapping
Daniel: EAD adherence is really the highest tier
Greg: Defining these tiers and standards can be a work plan item
Kevin: MARC is constantly considered at Columbia University, a robust MARC implementation within ASpace would be ideal
Greg: We should explore how DACS applies to ASpace, documenting how it is implemented would be valuable
Kevin: We should look towards documenting existing import and export mappings for at least EAD and MARC, and get these up to date
These are behind by more than one year
Bria: In the Migrations Sub-group, having a path for getting these mappings updated would have been valuable
Greg: Ensuring that communicating that a certain element must be updated in the mapping alone would be a great contribution
Kevin: This would likely be offered as instructions to community members in how to create JIRA tickets for review
Documentation
Christine: Much of the ASpace documentation is being migrated to Confluence, hence it might be best to explore migrating this mapping documentation here as well
Kevin: To what extent could some of this process involve documentation generated from the code base?
Christine: This is difficult to determine, but when changes are made to the API, there can be documentation updates which are generated
Not certain as to whether or not this could be supported for export/import functionality
Note that Data mapping is not a part of the technical documentation
There are a few spreadsheets which are linked from the general documentation
Christine: The technical documentation focuses upon what is involved in installing and deploying the application
There has not been a full effort to update the MARC export/import maps due to limited developer resources
MARC Mapping Concerns
Migrations Working Group found that there are some long-standing, complex issues regarding the importation of more obscure MARC fields
It would be best to try and break this down into actionable tasks
Kevin: Some of the behavior might be adjusted within the JRuby code base
Adjusting the field-level mappings for MARC export/imports can perhaps be demonstrated or documented for the community
Christine: This group should decide what the way is regarding the default/”one true way” to support default mappings
Support for Emerging Standards
There should also be an understanding that the standards are vast, and that there might be a need to call on expertise from outside of the community
Controlled vocabularies might be an area where catalogers would be preferred in terms of inviting colleagues to collaborate
EAD3 is still also a fairly new standard, and expertise might need to be invited
RIC is another standard which should be considered
Exploring how difficult it might be to support Records in Context would be desirable as well
TS-
...
DACS membership ensures that we have parties who are engaged in the development and finalization of this standard
Perhaps we should
...
consider a call to the general Technical Advisory Committee enquiring about DACS support once work with the DACS progresses
Work Plan Tasks and Goals
Defining our level of commitment to various standards
Addressing various mappings (this will need to be broken down into tasks, and we will need to ensure that we clearly define our level of commitment)
How DACS integration is supported and how tooltips are in sync.
Addressing dev. tickets and to what extent a request to improve a feature will be rewarding to the community
Offer a mechanism to provide feedback
Next Steps
Offer We should offer an e-mail on the Wiki where we define the work plan items
Break We should break them down on to tasks
In four weeks, assign the specific tasks, and define a timeline for each of these
Scheduling the Next Call
Next TAC call is scheduled for two weeks
...