Thank you to everyone that attended and contributed! We are very grateful!

Introduction

@Valerie Addonizio

Introducing the 2021-2022 Metadata Standards sub-team and Metadata Standards in general.

Join us! Make a difference in Aspace today! Look out for a call for nominations on the AS listserv, blog, and Google Group in April. Remember that non-Aspace Members are welcome on the Technical Advisory Council (TAC), of which this group is a member.

For any questions, please email this year’s Nominating Committee Chair Nick Zmijewski (zmijewski[at]industrialarchives[dotorg]) or ArchivesSpaceHome[at]lyrasis[dotorg].

Tiers of Support

@Valerie Addonizio

As we began to share the draft Tiers of Support, we got general approval of the need to be clear about AS's relationships with metadata standards. We also received pointed feedback along two tracks.

1. We were conflating “supporting a standard” in that one can follow a data model in AS and “exporting compliant records” as in one can serialize data from AS into a valid record within a particular namespace. 

2. Our choice of standards was flagged as being very US-centric, due mostly to its reactive stance.  If the goal is to make ASpace useful to the community outside the U.S.—and we believe that it is -- we need to adopt a proactive stance. Offering support to additional standards may encourage wider adoption of ASpace outside the U.S., subsequently resulting in greater engagement with the tool by that community.

It is worth underscoring that not only can no system support all standards all the time, but the human time and attention available to work on standards is finite.  Some sort of prioritization is inevitable, and we're ultimately seeking to make those choices transparent. With that background, we have a series of discussion questions we would like to pose.

• Why you use the standards that you are using?  For compliance reasons or data exchange reasons? 

• What does it mean for AS to be standards-compliant? That its data model support every standard, or that it can import/export (through mappings) every standard?

• What should be the balance of a support between “supporting a standard” in that you can follow a data model in AS and “exporting compliant records” as in you can serialize data from AS into a valid record within a particular namespace?

• What happens if a standard conflicts with another?

Updates to the MARC Importer

@Elizabeth Roke

Current copy of the MARC Importer Mapping

The current MARC importer mapping spreadsheet is the result of 3 terms of work by the Metadata Standards subcommittee. It documents which fields/subfields are imported into ArchivesSpace through the MARC importer, how they are imported, and (new this term) mappings to DACS elements of description.

To simplify the importer as well as support standards-based description, the Metadata Standards subcommittee proposes to only support the import of fields that have a DACS mapping as the default behavior in ArchivesSpace. We also propose to add a few core fields left out of the original importer: 264, 555, 583, 584, 852.

Community MARC Discussion

@Kevin Schlottmann

Current behavior:

The MARC importer attempts to separate numeric and textual information in the 300$a, assigning the former to an extent value and the latter to an extent-type value. If the parser fails, a default of 1 linear feet is inserted, presumably because extent is a required field and the import would otherwise fail.

As an aside -- if you bulk-imported MARC records into ArchivesSpace, check to see how many 1 linear feet collections are there - you might be unpleasantly surprised.

5 ǂf boxes ǂa (3 ǂf linear ft.)
Should this pattern be supported? How should this be parsed?  How should all of that punctuation be handled?

If an extent cannot be parsed, ASpace supplies “1 linear feet” and does not warn the user. We propose that if the 300 field cannot be parsed, the import should fail. Thoughts?

A recent ticket also noted that 300$f fields are ignored entirely.

Preview of EAD2002 Mappings

@Regine Heberlein