Workplan
2021-2022 Metadata Sub-team Work Plan
...
Completed an update to the MARC importer with significant improvements:
Mapped MARC elements to DACS elements and prioritized DACS mappings
Documented missing behaviors and created tickets for same
(ERR)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1568
(ERR)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1567
(ERR)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1565
(KS)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1260
(ERR)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1566
(KS)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1557
(VA)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1411
(VA)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1410
(VA)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1409
(VA)Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1408 Identified behaviors that can be removed and simplified
Completed re-working and actual data modeling for the EAD2002 importer with thanks to Regine
Addressed default behavior for MARC 300 fields
Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1260 Identified desired behavior for logging
Jira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1558 Commented on tickets as appropriate [list of tickets]
Presented at the 2022 Online Forum and solicited community feedback
Include stats that I generated after the Forum
Expand | ||
---|---|---|
| ||
On compliance versus interchangeability
On Elizabeth’s MARC topic
|
Piloted working meetings to help members get work done - it was acknowledged as a good idea but it didn’t work for everyone
Improved reactive strategies for tracking changes
Tested and implemented https://app.github-file-watcher.com/ to be automatically notified of changes made to the import/exporter code
Tested and implemented a subscription to a Jira filter for the Metadata tag
Tiers of Support - Attempt at a more transparent process for how we do what we doTask Force idea - Want to suggest an ad hoc taskforce to update the ASpace data model
An old (pre-container and location modeling) entity relationship model is archived in the WaybackMachine: https://web.archive.org/web/20150324043730/https://www.gliffy.com/publish/2269861/
Priorities for next term
Continue work on the EAD importer in earnest. Plan work to accommodate those who may be able to read Ruby and those who cannot. As a preview for next term, I asked Jared to give his feedback on the work compared to the work just undertaken for the MARC importer:
Expand | ||
---|---|---|
| ||
I think it will be a little more difficult for those folks who are not used to reading Ruby then it was for the MARC importer. Unlike the MARC importer, The EAD importer uses a lot more generic templates (methods) for dealing with XML chunks. For a newcomer I think it would be much more difficult to look at this code and make sense of how ASpace in pulling in EAD xml data and transforming into its local format. Because of the complex nature of the EAD xml people looking at the code will need to be able to navigate through several Ruby methods to understand how the data is being pulled and mapped (this means skipping around the code depending on what chunk of EAD is being pulled). Documenting the EAD exporter will require folks who have a strong background in the EAD tag library (given), but I also think that it will require some people with a fairly high level of comfort reading Ruby. I think an ideal subteam to work on such a project would be two people really familiar with the common EAD encoding practices (and the Tag library as a whole) working on importing test files and looking at the results and 1-2 folks who were comfortable reading Ruby to translate what the code is claiming to be doing. |
Revisit Tiers of Support as a principles document instead of a statement on scope
Spec for dropping MARC import support (if not completed by this term)
Pull all the non-core fields (2xx, 3xx, 754, 856) except the 5xx’s; for the 5xx’s, everything that is a core field gets mapped, but everything that is a 5xx just gets a mapping to a local note, like a 590. We know this a relatively big change, maybe put this in the roadmap, so that it doesn’t happen quietly. Elizabeth volunteers to write that spec, including the justification. You’ll get a list of what was imported.
Spec for
, folder for spec documents here: https://drive.google.com/drive/u/1/folders/1G4ACVJ9r3FUfStsnyZkDJWbyU-bErZzlJira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-547 Bring up the retiring of MARC behaviors at the next joint UAC/TAC meeting, which will be in the fall. Elizabeth Roke nominated to handle that communication
If we get Kevin’s ticket,
we should do an email announcement to the listserv and Google GroupJira Legacy server System JIRA serverId 36c489e2-4fb0-353a-985b-64038401be2f key ANW-1558 NEW Task Force idea - Suggest an ad hoc taskforce to update the ASpace data model
Continue working on the justification of that idea as recorded in this document https://docs.google.com/document/d/1-4E1BYAGT-GCAWLZaWwtsPgeGJqnt6y04e6r82EYxCY/edit?usp=sharing (TAC-MD subteam members should have access to that link without a problem)
Note that there is an old (pre-container and location modeling) entity relationship model archived in the Wayback Machine: https://web.archive.org/web/20150324043730/https://www.gliffy.com/publish/2269861/
NEW Pilot a Rotating group of ex officio’s from Metadata who sit in on Dev Pri meetings
This excellent idea came from the acknowledgement that there’s only so much we can ask of our fellows to alert us to changes, and sometimes they may simply not be aware that these changes will impact TAC-MD
The idea was raised that we begin a rotating roaster of Metadata reps who sit in on Dev Pri meetings to listen and know when a ticket should be tagged for us to review. This is a strategy to get us involved further upstream.
Elizabeth volunteers, Kevin volunteers
Not sure whether it rotates through the year or by the year, i.e. do different folks sit in on different meetings throughout the year or is one member rep determined per term?
RiC review
Essentially we know we absolutely must render a verdict on this, but we decline to do so on a draft. We have doubts about the stated aspirations (transmission standard, descriptive standard, one ring to rule them all). We want to be included in the decision of how ASpace reacts, and not just the recipients of said decision.
...
Start doing | Stop doing 🛑 | Keep doing |
---|---|---|
|
|
|
Recommendations for finishing up this term
...
Recommendations for being included
...
further upstream was one of our last kind of unsettled tasks for term, so it was discussed as part of the retrospective.
A reminder on some background context:
Some of this feeling was generated after all the changes that came with 3.0, but we’ve moved forward on that concern forgetting that we were invited to participate and declined. So this is about aligning both our own expectations about our work and being included further upstream in changes.
This is a good example of where things that the metadata group should weigh in on are buried in specification documents and tickets. Note that the specification includes a request to amend the EAD and EAD3 exports
Communicate it to Christine, the developers, but also TAC and Dev Pri.
More about a heads up than an approval process; fundamental to needing to track changes to documentation. Even if it becomes the primary job of this group to actively document and track those changes. We need to be tagged any time anything touches an importer/exporter
Actionable tasks and ideas
- Mention tagging Metadata at the final meeting of this term
- Mention tagging Metadata at the first meeting of next term
- Ex Officio idea! Seek orange text in the sections above for more details; that idea came out of this last minute discussion
Leadership for next term
Lead: Regine Heberlein
...