...
There were some tickets which might not need to be evaluated any long
ANW-412: VRA core for exporting digital objects
This is a fairly old ticket, there was disagreement about whether or not this was even desirable
Linked issue was closed as complete/duplicate
We are primarily concerned with the published mappings for the tier 1 standard
Christine
This is from the early day of the program…this can be used for linking to more robust digital object metadata
Most aren’t using ArchivesSpace with VRA core to provide more robust metadata for digital objects
Important for ASpace to always be thinking of what should be supported for core
ANW-475
Lydia noticed that there is a Dublin Core mapping already
Is this subteam going to evaluate this mapping?
Christine:
Project was ongoing during 2017, Dublin Core map is pretty close to the end
It is Dublin Core and not MARC
We can reach out to Adrian Pruitt - it might be worth investigating, as the mapping seems to be fairly far along
We should then keep this ticket upon, we are unlikely to get to it this year
We need to prioritize this as Tier 1
ANW-1047
There are inconsistencies in MARC relator exports
Some export as translations, and some as values
Not certain which should be exported
Christine:
Difference is in something in the role field vs the relator field
We probably want to look a bit further to RDA in order to use the translation
$4 is the value
Some systems prefer the code to the translation
We need to undertake research for this
Kevin will research this with cataloging colleagues
Kevin will make the comment once he has done the research
Review Agent Mappings
Agent Module being developed by Lyrasis
Test server deployed this week to test the agent module
EAC-CPF exporters/importers being developed
MARC authority features also being implemented
This group would be valuable in testing and providing feedback
Timeline of two months
Exporters/importers might require more time for implementation
If so, this would delay the release of the Module, all features should be released simultaneously
How will this impact the other work?
Prioritization
What can we realistically get done?
MARC bib. import needs to be finished
EAD still needs to be finished
We also need to adjust exports
Export review process might be deprioritized for the next phase of this subteam
James can take the lead on testing the agent module
Determine what it should be rather
No reason to compare the existing EAC-CPF map
James must evaluate the new EAC-CPF map
Need to review EAD3
How do we feel on deprioritizing export work?
Group consensus to leave this for the phase held for next year
MARC Import Review Process
How do we want to publish the findings?
Offer the existing spreadsheet for download?
Is there some other way to publish this?
MARC 520 fields (scope content and abstract)
Indicators: put into general note types, and this is an error
This results in scope notes being placed into 500 fields upon (re)export
Kevin proposed to create a bug in JIRA
MARC 5XX
583 processing note should be handled
This is pretty heavily used and has a clear analogue in ArchivesSpace
Ability to import 555 and 856 fields
URLs are stored to link out to other descriptions
Often these link out to finding aids, but currently they are not supported in core for imports
Columbia required customization for these fields
Should we take time in order to determine the best default behavior?
Perhaps we should request from Lyrasis their guidelines for how they typically support this with customizations
This very much depends upon the infrastructure
For Columbia, 555/856 URLs point towards the rendered HTML
Maybe we don’t change the import capabilities but instead document how it has been done for other institutions
555 or 856 or both?
Kevin has seen them used interchangeably and simultaneously
How often are those fields the location of the EAD
Post to the listserv in order to see about putting this ticket in as a feature
MARC 65X
Documentation doesn’t outline what is happening
The documentation just needs to be updated, the behavior is very intuitive
MARC 6XX/7XX
Support for Agents
130-630 appear to work
730 does not
This is probably just an oversight, and this is not documented at all
MARC 1XX field is not correctly respecting the source field
This is worth a bug ticket
Otherwise, end up with dirty agent data
Might not require a ticket, if it this isn’t reflected in the new Agent Map, then this behavior will define the behavior for the new Module
Importing existing authority data using URIs
This feature should be supported
Kevin will route that to James