EAD4 comments: Keep EAD easily adoptable by any institution (aspects adding a potential overhead)

[vns2]

Creator of issue

Mary Lacy Senior Archives Specialist, Manuscript Division, Library of Congress mlac@loc.gov

The issue relates to

• [ ] EAC-CPF schema issue
• [ ] EAC-CPF Tag Library issue
• [x] EAD schema issue
• [x] EAD Tag Library issue
• [ ] Schema issue
• [ ] Tag Library issue
• [ ] Suggestions for all schemas
• [ ] Suggestions for all Tag Libraries
• [ ] Other

Wanted change/feature

• Text: At this time, the Library of Congress is putting its efforts into trying to get our EAD3 finding aids in and out of ArchivesSpace, which has not implemented the current EAD3 version, and we do not foresee having the capacity to adopt the next version, EAD4, in the near future.
• We are finding this EAD version is radically different from either EAD2002 and EAD3; it seems that any hope of adoption rests on repositories using archives management systems to create any new EAD instances, as the new structure removes much specificity from the schema and requires use of additional namespaces while reducing the number of tags but requiring extra overhead to make them work.
• Although the tag names will be more human-readable by expanding and camelCasing (for instance, <did> becomes <identificationData>, the added length of the tags and extras (namespace declarations and need for repeated <formattingExtension> to enable access to HTML formatting-style tags) introduces much visual noise for anyone hoping to work with the XML document, as well as impacts performance by making some of our very large finding aids even larger.

The specific comment regarding <chronlist> has been added to #118 and will be dealt with in that context. This issue here will be kept for the general feedback on keeping EAD easily adoptable by any institution.

[MicheleCombs]

I'd like to second Mary's comments above. It's critical to keep in mind that EAD has many users who still encode by hand and/or who don't have much (perhaps any) tech support to assist them with things like making additional namespaces work. Changes to a standard that is used by people with widely varying technical skill sets must support all of them. Otherwise we risk creating a "digital divide" between high-tech and low-tech users, and further disadvantaging institutions that have less time, money, and staff. I understand the finding-aids-as-data push, but let's not forget they are also documents, created by and for individual people. They're not just data files created by and traded amongst databases and scripts. In addition to Mary's points, these added complications such as the need for multiple namespaces will make it harder to teach EAD to the next generation of archivists, which in turn means they'll be less familiar with it, less able to troubleshoot it, and less able/willing to advocate for its adoption and use.

EAD doesn't need to be all things to all people, but it should be easily adoptable by any institution, not just the tech-savvy ones.

[kerstarno]

Will be discussed by TS-EAS during their meeting on 12/13 August 2024 at the SAA Annual Meeting.

[jallibunn70]

Since I can't be present on August 12-13, I'll amplify here: Throughout its history, the literature has shown that EAD is difficult for most institutions to adopt. The Building a National Finding Aid Network (NAFAN) reports amplify this to the sky. This is absolutely the most important issue for the group to work on, and I look forward to seeing the notes from a robust discussion of this in Chicago!

[jallibunn70]

In case you haven't yet seen the NAFAN reports, they are all available from this page