Establish <function> more as a related entity rather than a piece of descriptive information

[kerstarno]

Creator of issue

1. Kerstin Arnold
2. TS-EAS EAD team lead
3. @kerstarno
4. kerstin.arnold@archivesportaleurope.net

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: Review the use of <function> and <occupation> across EAD and EAC-CPF, including conversations had in the Functions sub-team and considering that both could form under the RiC entity "Activity".
  • In EAD, both elements are currently sub-elements of <controlAccess> (or <controlledAccess>), i.e. they are used with a required and repeatable <part> sub-element plus a series of attributes with regard to linking to vocabularies, which in EAD 4.0 would be @valueURI, @vocabularySource, @vocabularySourceURI and the element <targetRole>, plus @conventionDeclarationReference which could be used to point to any rules applied in formulating the elements' content.
  • In EAC-CPF, both elements are defined as single elements, i.e. they include a required and repeatable <term> sub-element and also allow for one of the date elements, <placeName>, and <descriptiveNote>; they also allow for @valueURI, @vocabularySource, @vocabularySourceURI (and @conventionDeclarationReference), but not for <targetRole>.

[kerstarno]

The EAD sub-team discussed <function> and <occupation> during their meeting on 24 November 2023 and again during their meeting on 15 December 2023, the second time in the more general context of discussing relations in EAD.

For <function>, it has been decided to establish the element more as a related entity rather than a piece of descriptive information, along with <agent> (#58) and <formAvailable> (#65).

• [x] Move <function> out of <controlaccess> and <index> (for the latter two see #67)
• [x] Add <function> as a required and repeatable sub-element to <functions> (#68)
• [x] Adapt <function> to the content model defined in EAC-CPF 2.0
  • [x] Remove <part> and add <term> instead as a required and repeatable sub-element
  • [x] Add an optional choice between<date>, <dateRange>, and <dateSet>
  • [x] Add <placeName> as an optional, repeatable sub-element
  • [x] Add <descriptiveNote> as an optional, not repeatable sub-element
  • [x] Adapt @audience
  • [x] Remove @altrender
  • [x] Add @target
  • [x] Rename @lang and @script to @languageOfElement and @scriptOfElement
  • [x] Replace @identifier with @valueURI and @source with @vocabularySource, add @vocabularySourceURI, and remove @rules (replaced by @conventionDeclarationReference, see next point)
  • [x] Add @conventionDeclarationReference, @maintenanceEventReference, and @sourceReference
  • [x] Apply camelCase spelling to @localType and add @localTypeDeclarationReference
  • [x] Add an option to include attributes from any other namespace
  • [x] Remove @encodinganalog
  • [x] Remove @relator (replaced by <targetRole>, see next point)
• [x] Add <targetType>, <targetRole>, and <relationType> as optional and repeatable sub-elements to <function> (see #33 for the detailed definition of these elements)

For <occupation> as sub-element of <controlaccess> and <index> see #67.

[kerstarno]

In a future revision of EAC-CPF, <targetType>, <targetRole>, and <relationType> would need to be added as optional and repeatable sub-elements of <function> (see #33 for the detailed definition of these elements). There might then also be the question whether this would be the same for all other singular elements.

[kerstarno]

Tested with the XSD and the RNG and can confirm that this has been implemented as described.