...
Feedback from the Sub-Team:
This is a weird history, as people have not encoded language; They have chosen to use mixed content
Language of description is not a DACS elements; Only language of material is
We should still attempt to export this information in a structured way
We’re encoding EADs with mixed content given that the toolkit encoded it as such
EAD3 was the intended version for enhanced support for extended language encoding
EAD2002 is far more restrictive in structure
Next steps: Reach out to Corey to determine if there was any intent here, and if there was, determine what the next step would be for the Sub-Team
Another Ticket: https://archivesspace.atlassian.net/browse/ANW-805
This was raised by Dev. Pri., but the process for forwarding this to the Metadata Standards was not in place
Issue was how the “published” status should work, it seemed to be that there was a lot of discussion in the comments for this
The interaction between the “published” status for the Digital Object in ArchivesSpace, and how this is encoded within the EAD
This will be added to the agenda for the next scheduled meeting
Ideas from December TAC Meeting
...
Kevin drafted a Confluence page (Import/export mapping review process)
These directions should prove to be quite useful for providing guidance to future Sub-Teams
Perhaps referencing the code in certain cases might be more straightforward for discussion the import process and mappings
Bulk Import Issue (https://archivesspace.atlassian.net/browse/ANW-1002)
Daniel: This should go directly to the Dev. Pri. meeting given that this has already been evaluated by this group
Christine created a dedicated test server at http://metadata.lyrtech.org/staff
DACS Tooltips Spreadsheet Update
Most of the progress has been quite straightforward
The priority of this is significantly less than the Importer/Exporter testing
It might be more efficient to proceed by perhaps setting a month for dedicated focus upon this and finalizing it
MARC-XML and EAD Import/Export Sheet Updates
Bugs are extremely difficult to test
With a massive MARC import, Columbia did not find that many of the more obscure fields were used
MARC 342 tag represents a case which is probably a very extreme edge case
Maybe something like paring down the imports for this process might make it much easier
We should explore defining a core group of minimum supported fields
Prioritizing testing by determining which elements in MARC and EAD are used
There have been usage surveys to try and find points at which we could reduce the complexity offered by MARC where use cases aren’t relevant
Meeting adjourned at 16:00 EST