Add an option to encode any other local identifiers for a component description

[BrigitteMichel]

Creator of issue

1. Brigitte Michel (michel@abes.fr)
2. Abes (Agence bibliographique de l'enseignement supérieur = Bibliographic Agency of Higher Education)
3. for WG EAD in french libraries (gt-ead-b@listes.abes.fr)

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: It is essential to be able to provide other identifiers that a component may have in other databases. These identifiers do not concern the document unit (material being described) itself (<unitId> is therefore not suitable), but the description identifiers of the same document in other databases (digital libraries, collective catalogs, specialized databases, AIS). The information must be repeatable: it cannot, therefore, be an attribute of <c>, but a repeatable element defined within <c>, <c01>, etc.

Suggested Solution

1. To Allow the <otherRecordId> element within <c>
2. Or to reuse the <identityId> element defined in EAC
3. Or to create a specific element like <otherComponentId>

In all three cases, we need to decide whether we can use the @id attribute or if a specific attribute is needed (@valueURI or @normal) to ensure better control of the data than free text [text]

Context

• Text: The same document unit may have different identifiers in a collective catalog like Calames, in a local database AIS, in a research corpus, and in a digital library, which may be in different formats (EAD, DublinCore, MARC, TEI, etc.) with complementary description elements: for systems, links, updates, and interoperability, we must be able to mention these other identifiers. The challenge is not necessarily to enable direct links to the public but to facilitate data administration (export or import between databases) or updates
• Example:

  <c id="Calames-20106161761991412">
  <identificationData>
  <unitId localTypeDeclarationReference="BPEAD_unitid" localType="cote" countryCode="FR" repositoryCode="751041006">Ms.2.939</unitId>
  <unitId localTypeDeclarationReference="BPEAD_unitid" localType="ancienne cote">BNUS. Hollandais 3</unitId>
  <unitTitle>Pastard, staand, en loopende geschriften, van verscheyds meesters</unitTitle>
  </identificationData>
  <otherRecordId localTypeDeclarationReference="Calames_AutreIdentifiant" localType="BibNum" vocabularySource="Gallica" valueURI="https://archivesetmanuscrits.bnf.fr/ark:/12148/cc96693h/cd0e759"/>
  <otherRecordId localTypeDeclarationReference="Calames_AutreIdentifiant" localType="AIS" vocabularySource="BNUS-Docuteam">416574561</otherRecordId> 
  ou
  <otherRecordId localTypeDeclarationReference="Calames_AutreIdentifiant" localType="AIS" vocabularySource="BNUS-Docuteam" id="416574561"/> 
  </c>

NB 1 about <recordId> child of <control>: where to declare the URI of the EAS instance ; why not in attribute @valueURI? NB 2: I don't understand the possible use in <control><recordId> of attribute @target "ID of another element"

[BrigitteMichel]

<otherFindAid> could also have been an option, but the name itself is characterized by a logic of describing the whole (FindAid) rather than data and record unit. Furthermore, the <p> element is contradictory to the necessary control for an identifier.

[kerstarno]

Thank you for this comment, @BrigitteMichel. TS-EAS will add this to the list of comments to be discussed at their meeting on 12/13 August.

Just wanted to reply briefly to your questions and the point about <otherFindAid> as a possible alternative:

• Currently the idea is for the URI of the EAS instance itself to be encoded in <findAidDesc>, using the attribute @href. EAD3 had already moved this from <eadid@url> to <representation@href> and as <findAidDesc> is meant for any representation format of the archival description encoded in the EAD XML file, this also includes the EAD XML file itself as one such representation format.
• @target with <recordId> could e.g. be used to point to a <conventionDeclaration> in case the record identifiers follow a specific institutional, regional, national, or international rule or to <maintenanceEvent>in case the record identifier has been changed as a result of a maintenance event (e.g. when splitting one EAS XML file into two or more and extending the original record identifier by adding "a", "b", "c", etc. to it). Sub-elements of <control> generally don't have the specific attributes @conventionDeclarationReference or @maintenanceEventReference, which are reserved for elements from the archival description part.
• While I get your point about the name "otherFindAid" and while we have decided not to change the name in this case in acknowledgement of the century-old concept, we do understand the term "finding aid" more generally in the context of EAD 4.0. I.e. I would argue it could also apply in this case here (though this maybe is an argument for considering a name change after all). As <otherFindAid> allows for @valueURI and - in EAD 4.0 - does not actually require to have any sub-elements, you could have an encoding such as <otherFindAid localTypeDeclarationReference="Calames_AutreIdentifiant" localType="BibNum" vocabularySource="Gallica" valueURI="https://archivesetmanuscrits.bnf.fr/ark:/12148/cc96693h/cd0e759"/>
• The @id attribute should not be used in either of these possible scenarios as this is purely to identify the XML element in question itself.

[kerstarno]

For reference: a similar suggestion was made in the revision from EAD 2002 to EAD3, including an additional example use case, see https://github.com/SAA-SDT/EAD3/issues/270