...
Introductions for Participants
Discussion topics
Time | Item | Presenter |
|---|---|---|
Introductions (Ice Breaker Question: Do you have a pet, and if so, what kind?) | ||
Metadata standards (for descriptive and for encoding use cases) which should be supported as default ArchivesSpace solutions | ||
Status of the Describing Archives, a Content Standard (DACS), and its support within ArchiveSpace | ||
Maintaining published import and export crosswalks for metadata in ArchivesSpace | ||
Documenting ArchivesSpace data mappings (for example, from MARC to EAD) | ||
Scheduling Future Meetings |
Action items
Notes
(Introductions were held)
Overview of the Sub-team
We are tasked to come up with a work plan and activities which can be reasonably executed over the next year
Hone We should hone in by the end on a rough work plan and begin scheduling
Moving ArchivesSpace to support the identified metadata standards
Reviewing the Sub-team Charge
When drafting a charge for the new Sub-team
Might Note that we might need to prioritize different parts of the charge
We also might not get to every item of the charge
This charge can be edited throughout the year
Around ArchivesSpace, addressing metadata standards was seen as a real need
This charge seems to ensure that this need is going to be addressed
Metadata Standards
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
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
Data mapping is not a part of the technical documentation
...