Encoding agents

[SJagodzinski]

Feedback from @dpitti on encoding agents in EAC-CPF 2.0

Concerns: <otherEntityTypes> #141 <otherEntityType> #142

Creator of issue

1. Daniel Pitty
2. SNAC

The issue relates to

• [x] EAC-CPF schema issue
• [x] EAC-CPF Tag Library issue
• [ ] EAD schema issue
• [ ] EAD Tag Library issue
• [ ] Schema issue
• [ ] Tag Library issue
• [ ] Suggestions for all schemas
• [ ] Suggestions for all Tag Libraries
• [ ] Other

Wanted change/feature

The first observation is that <entityType> is required, and thus there is not way to have an alternative to the c p and f.

Second, <otherEntityTypes> must follow <nameEntry>.

Third, I am not sure why the plural.

Context

The example given:

<identity>
    <entityType value="family"/>
    <otherEntityTypes>
        <otherEntityType>
            <term>Group</term>
            <descriptiveNote>
                <p>Family is a kind of Group.</p>
            </descriptiveNote>
        </otherEntityType>
        <otherEntityType>
            <term>Dynasty</term>
        </otherEntityType>
    </otherEntityTypes>
 </identity>

I would note that Dynasty would be a family term used in the forming of the family name in RDA. A Dynasty is a kind of family.

[kerstarno]

As an initial reaction to the observations:

• Ad 1. <entityType> has been mandatory in EAC-CPF so far and if I remember correctly, we decided to stick with this for reasons of interoperability, i.e. to at least have one element that is predictable. We also opted against extending the list of predefined values for <entityType> at this current stage due to a point that is made in the feedback document itself - "With respect to the potential impact of RiC-CM on EAC-CPF (and EAD or EAWhatever), you might want to differ in this round of revisions, as I think piecemeal may lead to implementation issue, particularly if someone uses a RiC in EAC-CPF feature, it might not play well down the road with a schema for fully oriented to RiC, if such at some point is desired."
• Ad 2. This is due to the generally applied revised sequencing of sub-elements that has required elements, in this case <nameEntry>, appear before optional elements, in this case <otherEntityTypes>. If we were to change this here, we would need to review this in other cases as well - or drop this revised sequencing altogether.
• Ad 3. For the same reason for which EAC-CPF has other plural elements like <functions>, <occupations>, <places> etc., i.e. to "serve as wrapper elements for one or more singular elements of the same kind" (quote from revision notes).

[SJagodzinski]

EAC-CPF meeting 3 September 2021:

• there was a community request around corporateBody to be able to be more precise
• we will include a statement in introductory materials that we’re following the official ICA standards still
• keep as is, and update examples, etc.
• The example of family -> group + dynasty (e.g. why list group, if dynasty is classed elsewhere as a group?). Perhaps use an example that includes a translation, instead?