Review the availability of @localType, especially with regard to a consistent approach to elements of the same kind (e.g. all -Type and -Role elements)

[BrigitteMichel]

Creator of issue

1. Brigitte Michel (michel@abes.fr)
2. Abes (Agence bibliographique de l'enseignement supérieur = Bibliographic Agency of Higher Education)

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 difficult to understand why these two attributes are not allowed in <placeType> and <unitType> while they are allowed for the elements <agentType>, <relationType>, and <targetType>, which also define types. There also are other elements such as <reference> and <unitTitle> that might benefit from a local type option.

Context

• Text: In <reference>, @localType would allow the definition of a typology that replaces and deepens the distinction between 'archival resource' / 'published resource' lost with the disappearance of <archref> and <bibref>.
• In <unitType>, it would allow the definition of a typology for specific management issues (units of digital space (bytes) / spatial management (linear meters) / duration / content (number of PDF pages)).
• In <unitTitle>, it would allow distinguishing titles created by the archivist from titles found on the documents themselves, and/or the nature of transliterated, translated,... (see the list defined for @type in <unitTitle> in EAD2 (https://www.ead-bibliotheque.fr/guide/donnees-du-did/unittitle/)).
• In <placeType>, it is necessary if <physloc> would become <place> (cf. #141) to distinguish between places external to the institution and internal locations.

[kerstarno]

This will be discussed by TS-EAS during their meeting on 12/13 August.

That being said, I think this touches on a more general topic in terms of consistency of where @localType should be available and where it shouldn't be. Especially for -Type elements it might rather be that none of these should actually have a @localType because the element in itself already provides an "open to all possibilities" approach as it allows for any text without any restrictions. If, in a specific application context, values within any -Type element are taking from a local/institutional or other type of vocabulary, this can be made explicit either by using the attributes @valueURI, @vocabularySource and/or @vocabularySourceURI or by using @conventionDeclarationReference and having that the convention/rule applied being named and described in <conventionDeclaration>.

I will add the point about <reference> to issue #116, so that it can be considered more specifically in that context.

As for <unitTitle>, that already allows for @localType.

[kerstarno]

Not discussed eventually during the TS-EAS meeting on 12/13 August due to time constraints. Will now be on the agenda at the EAD team meeting either in September or October 2024.