12 Comments

  1. Jackie, thanks for the kind and supportive comments on EAD3. Although we are no longer accepting comments on the current revision (although bug reports are still very welcome), my TS-EAD colleagues and I remain eager to hear from the community as they begin to grapple with EAD3 and the implications of the revision. One important change that was out of scope of the recent webinar is that after the final release of EAD3 we will be accepting comments on an ongoing basis, with the intention of fixing bugs and making minor backwards-compatible changes on an as-needed basis rather than letting them accrue to a critical mass. Significant changes or new features will still be saved for major revisions, but the community can expect EAD to receive more regular upkeep.

  2. I also don’t like the element named “foreign” – what’s “foreign” to you may be “native” to someone else. Why not just call it what it is, a coded value?

    • Karen, EAD element names are meant to be human-readable for their intended meaning, so calling it generally a coded value wouldn’t fit. But maybe something like ? ?

    • From what I understand, the point of foreign is that it’s foreign to the language in which it occurs. Par example that last phrase was foreign but wouldn’t be if I were writing this comment in English. This helps designate and display words which people may want to realize aren’t things they don’t know in English, because the person is ESL and the phrase is German. See also TEI.

  3. This is a very helpful run-down of the direction that this will be taking us. Thanks so much, Jackie!

    I’ve been thinking a lot about elements (like ) that will require enhancements. It would be great if a body (perhaps like ArchiveGrid, or even a module within our management tools like ArchivesSpace) could start thinking about a suite of enhancement tools for finding aids to make our data a lot more actionable. These could be reconciliation tools that could bring in LCNAF and LCSH URIs to controlled access points to make them more linking-friendly, a set of regular expressions that could identify normalized dates from date expression statements, or a validation layer that could identify when DACS single-level minimum elements are missing. It seems to me that our standards are bringing us much closer to a world of manipulable, linkable data, and now our data just needs to catch up!

  4. I’m really interested in working through how to implement the new set of elements and attributes available in EAD3 for physical description; specifically the physdescstructured and parallelphysdescstructuredset elements. These were designed with the complexities of electronic records in mind, but at first glance it seems they’ll prove useful for description of audiovisual materials as well, whose complexities sort of mirror those of e-records. For instance, where you want to include multiple ways of expressing a component’s extent, or where you have different types of physical records making up a single intellectual component.

    • To agree with and extend what Megan said about the physdescstructured elements: I’ve recently exchanged some helpful emails with Mike Rush (thanks, Mike!) about using terms from PBCore vocabularies in child elements of physdescstructured, such as unittype and physfacet. PBCore is undergoing a sort of revitalization due, at least in part, to the American Archives of Public Broadcasting project. This XML-based structural standard is especially useful for audiovisual materials, and it could provide needed guidance on how to state the name of a format (such as a 1/4-inch audio reel) and its most important physical characteristics (e.g., those that would effect playback, basic access). PBCore covers both physical and digital audio, film, and video. Changes in both the PBCore website and the standard itself are underway, but keep an eye on the website, http://pbcore.org/. The vocabularies are maintained in the Open Metadata Registry. Additionally, Mike suggested that relations (imagine pointy brackets around relations) could contain a wrapper element, namely objectxmlwrap, for metadata from a standard other than EAD — such as PBCore. relations can be used within archdesc and component elements (c01, c02, etc.), meaning we could jump into PBCore for a description of an AV item (or subseries, etc.), including, e.g., segments and instantiations as appropriate. For AV materials, item-level and even sub-item level description is often needed, and although such non-EAD descriptions could be linked to, e.g., in connection to a digitized segment of an oral history interview, it would be nice to have the option to embed the description in the finding aid. There’s work to be done in the PBCore vocabularies from what I can tell, and relations is experimental in EAD3, but is any of this worth pursuing? What do you all think? Thanks.

Comments are closed.