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 Introducing a new attribute @status for the elements <:0; to indicate their status as being "unknown" or "open" (e.g. for persons who are still alive). Adding the attribute @rules (from EAD3) to <:0; to briefly note the applied rule, plus adding an IDREF type attribute to <:0; to enable pointing to the corresponding <:0; for further details:0; Introducing a new attribute @status for the element <:0; to indicate the status of the name as being "authorized" or "alternative":0; Investigating the possibility of turning <:0; into an attribute as well. Alongside the expected changes for <:0;, the EAC-CPF team also is considering a name change from <:0;nameEntryParallel>:0; to a more general <:0;nameEntrySet>:0;. The use of the attribute @localType would then be recommended to indicate that all names grouped within <:0; 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. Identifiers used to distinguish and determine entities:0; Identifiers used to create unique locations within an EAC-CPF instance:0; i.e. the attribute @xml:0;source>:0; rather than <:0;. Furthermore, <:0; will be renamed more appropriately to <:0;identityId>:0;. To include a sub-element <:0;foundData>:0; with this new element to encode a brief description of the evidence data found in the (new) source:0; 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:0; To enable connections between the new element <:0; and the elements <:0;maintenanceEvent>:0; section to encode information about the source in general as well as about agent making the assertion and the date of the assertion.
Names
While in EAC-CPF it is relatively straightforward to use the element <:0;nameEntry>:0; plus <:0;part>:0; to encode names and their constituent parts, there remain questions around the appropriate use of its other sub-elements:0;authorizedForm>:0;alternativeForm>:0;preferredForm>:0;. 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 <:0;. The EAC-CPF team has discussed options to disentangle the current situation, e.g. by:0;conventionDeclaration>:0; in the <:0;control>:0; section of an EAC-CPF instance:0;Identifiers
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:0; e.g. elements <:0;recordId>:0;otherRecordId>:0; holding current and maybe previously used identifiers of the EAC-CPF instance:0;- Informational identifiers, e.g. the alphanumeric string representing the name of an entity as given in <:0;, which establishes a meaningful connection with the entity it represents:0;
- Non-informational identifiers, e.g. the primarily, but not exclusively numeric string of a globally unique and persistent identifier as given in <:0;entityId>:0;, which does not have a meaningful connection with the entity it represents:0;