Be part of forming the new version of EAD

Call for comments on the Encoded Archival Description

The Technical Subcommittee on Encoded Archival Standards (TS-EAS) calls for comments to improve the Encoded Archival Description (EAD). After a general assessment phase during the first half of 2021, TS-EAS wants to hear from EAD users of all types – single users, institutions with archival holdings, consortia and aggregators, software developers working on systems that support exporting to EAD-XML, etc. – what they are missing in the current version of EAD and what they would like to see in a future version of the standard.

Information about the current EAD can be found on the standard’s homepage at and input can be provided in two possible ways:

Feedback will ideally be as precise as possible, including examples to illustrate the suggestions and requests, and making sure to provide contact details, so that TS-EAS can check in on any additional information needed. Comments will ideally be formulated in English.

The call for comments is open until 28 February 2022 and TS-EAS are looking forward to the community’s feedback and proposals.

Survey: help us understand your needs

Archives Portal Europe (APE) has teamed up with Europeana to create a survey open to all archival institutions that are currently content providers to APE and/or Europeana, or that are potentially interested in participating. In particular, we wish to explore:

  • The benefits and advantages that institutions with archival holdings find in their collaboration with aggregators such as APE and Europeana, 
  • Potential concerns and doubts that you may have in your current or prospective collaboration, 
  • The connections that you see between these international aggregators and national, regional, or topic- or material-based aggregators that you might be collaborating with.

We are therefore inviting any institution with archival holdings – whether you already provide content to APE and/or Europeana or not – to answer this short, 10-minute survey by Thursday, 1 April 2021, and to share your thoughts with us. 

The survey is available in five languages:

and your input will be highly appreciated. 

Please also share this survey widely!

Proceedings from the Knowledge Infrastructures and Digital Governance workshop. History, Challenges, Practices

The University of Luxembourg, within the framework of the OPERAS-P project, organised an online workshop on the 7/8 September 2020 with the aim of combining theoretical and practical perspectives on digital research infrastructures and the challenges facing digital governance.

The proceedings are now available at this link. Archives Portal Europe was one of the case studies presented:

Will pigeons once again soar beneath the cloud(s)?

by Kolya Abramsky, Assistant Archivist at the George Padmore Institute, London

Siege of Paris 1870–1871, pigeon post medal by the artist Charles Degeorge. Available at <,_Pigeon_Post_Medal_for_French_Military_Communications.jpg&gt;

As the Covid-crisis unfolded, got worse, stabilised, and deepened again many discussions focused on the ‘hi-tech’ questions raised by the ‘Covid-crisis’ for archivists and records managers– the explosion in the use of Artificial Intelligence (AI) and algorithms, and of new remote working tools like Teams, Yammer or Zoom, and the implications for Records Management (RM), Information Governance (IG) and archiving. Instead, I ask whether we might see a resurgence of the most ancient and primitive information technology – carrier pigeons. The question – partly metaphorical, partly literal, and entirely playful – serves as a vehicle for posing uncomfortable questions about information technologies and systems’ vulnerabilities and fragilities in the worsening global crisis.

Pigeons have a long, and surprisingly enduring, role in the history of information and communication technology. From the dove’s pivotal role when Old Noah, so the legend goes, sought evidence of dry land, to the messenger pigeons of the Siege of Paris during the 1870 Franco-Prussian War, to their use in espionage by both sides during World War Two, and the Cold War. Pigeons played a limited, but important, supporting role in these times of systemic breakdown or inter-state conflict, when existing informational channels and technologies buckled or became insecure. Pigeons were used despite the existence of “more modern” information technologies, coexisting alongside the telegraph during the Paris Siege; radio, radar, telephone and code-breaking computers during the Second World War; and the massive Cold War expansion of information technologies including television, satellite broadcasting, early computers and databases.

Despite technological advance, the image of the pigeon has endured. The Universal Postal Union, the UN body on postal communication (founded in 1874), produced commemorative stamps with images of carrier pigeons to mark its 75th and 100th anniversaries. In 1957, similar images adorned Soviet stamps commemorating the ‘International Year of the Letter’. Interestingly, this same year saw that country revolutionise global communication by sending the Sputnik Satellite into space, while the US Army’s Signal Corps disbanded its Pigeon Service, citing “advances in communication systems.

Lest one say, “but that was then, and this is now, ‘The Information Society’ changes everything”, it is worth noting that as recently as 2010-2011 the Chinese People’s Liberation Army announced its 10,000 strong “reserve pigeon army”, as an “indispensable” element in “modern warfare”. The motives? “Pigeons are the most practical and effective short and medium distance tool for communications if there is electromagnetic interference or a collapse in our signals”.

The current ‘Covid-crisis’ has forced people world-wide to face systemic vulnerabilities and the possibility of systemic collapses: supply chains have ruptured; productive processes, including food production, have been disrupted; air, land and sea transportation has broken down, almost entirely; and, the global workforce has been disrupted.

So far, the world’s digital and informational infrastructure has held out. Staggering numbers of organisations, institutions, enterprises and individuals are ‘Working From Home’ world-wide. This has caused an unprecedented (and growing) explosion of internet use, for leisure (such as Netflix), virtual socialising, and especially for work-based communication through Skype, Zoom, Yammer, Teams, and other fora. There has been an increase in cyber-crimes. Rivalry is growing between Facebook, Zoom, and Google to produce the best remote communications technologies and capture market-share, and the US’ war on Huawei has intensified. However, another unnerving spectre is raised.

As the crisis worsens, could the internet and related global digital infrastructures also rupture, due to the combination of overload and reduced work force due to illness, self-isolating, or strikes? Additionally, digital infrastructure’s reliance on stable electricity supplies and global supply chains for hardware, raw materials and components, adds another layer of vulnerabilities. A temporary or longer-term disruption to the world’s digital infrastructure would massively undermine the fundamental material basis of digital RM, IG and archiving.

In such a far-reaching systemic collapse, might the erstwhile pigeon return, just as lowly candles unfailingly appear as saviours during major electric power outages? Undeniably, pigeon-based communication is horribly slow and unreliable, but, slow and unreliable is better than nothing. It is a matter of relative, not absolute, functionality. And, in the face of growing cyber-attacks, pigeons’ ability to evade detection may offer security. A 21st century cyborg-pigeon carrying gigabytes of digital information on miniaturised memory cards represents a formidable upgrade on the paper, or even micro-film, bearing 20th century pigeon. Pigeons do not ‘spill the beans’ under pressure.  And, crucial for the era of self-isolation, pigeon-post is virtually contactless.

‘The cloud’ is the global information infrastructure’s highest level. Nonetheless, the lower levels still exist – from internal onsite hard drives, to wooden shelving. Is there still room for the lowest level of all, the pigeon, to once again fly beneath the clouds? And, how high might it soar should the clouds clear completely? Information practitioners may yet debate whether to destroy, retain or archive that strange, obscure, and thoroughly unfamiliar message tube found on a pigeon’s leg…

To contact the author:  kolyaab[at]

EAC-CPF revision half-way into stage 2

Kerstin Arnold is the Technical Coordinator of Archives Portal Europe

After successfully releasing a minor revision of the Encoded Archival Context – Corporate Bodies, Persons, and Families (EAC-CPF) in December 2018, the EAC-CPF team of the Technical Subcommittee on Encoded Archival Standards (TS-EAS) is now half-way into the second stage of the standard’s major revision. While all current issues are discussed on GitHub and during the monthly team meetings, a few general topics emerged from these conversations that seemed to qualify for more in-depth analysis.

One day dedicated to EAC-CPF

Hence TS-EAS decided to have a one-day meeting on selected topics from the EAC-CPF revision, when meeting in the context of the Annual Meeting of the Society of American Archivists (SAA) in Austin in August 2019. The topics on the table were “Dates”, “Names”, “Identifiers” and the new addition of “Assertion Description”. It should be noted that some of the updates, which are detailed below, are still in flux and will require further conversations during the next few months.


EAC-CPF uses a variety of elements to encode date information, but it is only possible to some extent to express uncertainty about dates or even to classify part(s) of a given date range as unknown. The EAC-CPF team has been looking at the implementation of such uncertainty in other standards, including Encoded Archival Description (EAD 2002 and EAD3), the Extended Date/Time Format (EDTF) Specification, the Text Encoding Initiative (TEI) and the Metadata Object Description Schema (MODS). Based on this comparison, the suggested changes include:

  • Adding the attribute @certainty (from EAD3) to the elements <date>, <fromDate> and <toDate>;
  • Recommending the use of values inspired by EDTF such as “uncertain”, “approximate” and “uncertain and approximate” with the newly added attribute @certainty;
  • Introducing a new attribute @status for the elements <date>, <fromDate> and <toDate> to indicate their status as being “unknown” or “open” (e.g. for persons who are still alive).


While in EAC-CPF it is relatively straightforward to use the element <nameEntry> plus <part> to encode names and their constituent parts, there remain questions around the appropriate use of its other sub-elements: <authorizedForm>, <alternativeForm> and <preferredForm>. Meant to indicate the rule or convention, based on which a specific form of name can be identified as “authorized”, “alternative” or “preferred”, these elements – indirectly – also provide information about the status of the name given in their parent <nameEntry>. The EAC-CPF team has discussed options to disentangle the current situation, e.g. by:

  • Recommending more strongly that rules and conventions are encoded via the element <conventionDeclaration> in the <control> section of an EAC-CPF instance;
  • Adding the attribute @rules (from EAD3) to <nameEntry> to briefly note the applied rule, plus adding an IDREF type attribute to <nameEntry> to enable pointing to the corresponding <conventionDeclaration> for further details;
  • Introducing a new attribute @status for the element <nameEntry> to indicate the status of the name as being “authorized” or “alternative”;
  • Investigating the possibility of turning <preferredForm> into an attribute as well.

Alongside the expected changes for <nameEntry>, the EAC-CPF team also is considering a name change from <nameEntryParallel> to a more general <nameEntrySet>. The use of the attribute @localType would then be recommended to indicate that all names grouped within <nameEntrySet> are “parallel”, as per the specific use case in the US American context, or do all represent “former” forms of the name or “translation”-s of the name.


Talking about the various ways to identify an EAC-CPF instance, its versions, its parts, the entity – or identity – it describes, as well as related resources and related entities, the EAC-CPF team has decided to focus especially on providing more specific descriptions and more appropriate examples to clarify which ID element – or attribute – to use for which use case. As a starting point, three types of identifiers have been defined, one of which can furthermore be divided into two sub-groups:

  • Database primary keys, used to uniquely identify each record within a given context; e.g. elements <recordId> and <otherRecordId> holding current and maybe previously used identifiers of the EAC-CPF instance;
  • Identifiers used to distinguish and determine entities;
    • Informational identifiers, e.g. the alphanumeric string representing the name of an entity as given in <nameEntry>, which establishes a meaningful connection with the entity it represents;
    • Non-informational identifiers, e.g. the primarily, but not exclusively numeric string of a globally unique and persistent identifier as given in <entityId>, which does not have a meaningful connection with the entity it represents;
  • Identifiers used to create unique locations within an EAC-CPF instance; i.e. the attribute @xml:id providing identification for a specific element within the EAC-CPF XML.

With regard to identifiers of EAC-CPF instances that have been merged or translated into the current one, the EAC-CPF team has decided to promote the use of <source> rather than <otherRecordId>. Furthermore, <entityId> will be renamed more appropriately to <identityId>.

Assertion Description

In addition to the three topics on existing elements above, the EAC-CPF team also discussed a new feature request, which deals with enabling users to encode the source of specific information as part of an EAC-CPF instance. This becomes relevant especially when looking at potentially contradicting sources e.g. for the name of an entity or the date or place of birth of a person. Discussions are still ongoing with regard to this topic, but the intent is:

  • To introduce a new element called <evidence> or similar as sub-element to most descriptive elements within EAC-CPF;
  • To include a sub-element <foundData> with this new element to encode a brief description of the evidence data found in the (new) source;
  • To work with attributes to point to the exact element that includes the assertion and to refer to potentially contradicting assertions within the same EAC-CPF instance;
  • To enable connections between the new element <evidence> and the elements <source> and <maintenanceEvent> in the <control> section to encode information about the source in general as well as about agent making the assertion and the date of the assertion.

Next steps

The EAC-CPF team will tackle pending questions with regard to these topics as well as others, which still require further consideration, in the context of its monthly meetings between December 2019 and March 2020, culminating in a three-day meeting from 9 to 12 March 2020 in Berlin, Germany. We invite you to follow and participate in our conversations on GitHub at any time.