New attribute @status

[SJagodzinski]

Add the new attribute @status for a range of elements to define the elements status.

Creator of issue

1. Silke Jagodzinski
2. TS-EAS: EAC-CPF subgroup
3. [email protected]

The issue relates to

• EAC-CPF schema issue
• 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

Add the new attribute @status for following elements:

1. <nameEntry>: to indicate if a name is authorized or alternative.
2. Date elements: to indicate unknown or open dates
3. Elements with child <evident>: to indicate the ranking
4. <agencyCode>: to specify that the agency code is following the standard ISO5511

Suggested Solution

Definitions:

1. <nameEntry>: optional, limited values (authorized/alternative)
2. <date>, <fromDate>, <toDate>: optional, limited values (unknown/open)
3. Elements with child <evident>: optional, to be defined
4. <agencyCode>: optional, binary question

Context

Proposal as a result of the discussion on Topic: Names during the f2f meeting 2019, see minutes.

Proposal to solve #26, #32, #43, #15

[kerstarno]

I'm wondering, if there'd be a need to also have the option to differentiate the unknown status for <dateRange> rather than for its sub-elements. If yes, we might want to consider the values "unknown", "unknownStart" and "unknownEnd".

[kerstarno]

During their meeting on 1 November 2019, EAC-CPF team confirmed the use of @status with <nameentry> with a predefinded list of only two values: "authorized" and "alternative".

[fordmadox]

Based on the assertion-description comments, I'm wondering if we discussed using @value in place of @status? I'm not sure how I like the approach, but EAD3 already has four different controlled lists depending on the context of where @value is utilized, whereas EAC does not have the value attribute:

<ead:agenttype value="human"/>

vs.

<eac-cpf:agentType>human</eac-cpf:agentType>

In any event, if @status is introduced, I think that we'll need to be very clear with how it differs from @value (and I don't think that it would be enough to say that one is used in control, and the other is not). But with all of the example so far, including <dateRange>, it seems like @value would work just as well.

[kerstarno]

As a note with regard to the atrribute @value: issues #5, #6, #7, and #8 envisage to add this to the elements <maintenanceStatus>, <publicationStatus>, <eventType>, and <agentType> respectively.

As for differentiating between @value and a new attribute @status, I would say that @value provides the content of the according element in a "standardised" way by using English terms, while allowing the element to hold either local or other language variations of these. By this, @value is essentially doing the contrary of @localType, if you want to say so.

@status on the other hand, qualifies - or categorises - the content of the according element.

[fordmadox]

That distinction between "status" and "value" makes sense to me, but it might be part of the broader shared-schema approach since it would seem then that @value (https://www.loc.gov/ead/EAD3taglib/index.html#attr-value) and @normal (https://www.loc.gov/ead/EAD3taglib/index.html#attr-normal) are used for the same purpose in EAD3, whereas the definition and implementation of @value in EAD3 simply restricts it to the control section (since EAD3 adopted and slightly modified the "control" module of EAC).

[kerstarno]

True with regard to the aspect potentially being part of a broader shared-schema approach.

However, I am not sure I agree with @value and @normal (for sub-elements of <controlaccess>) having the same purpose in EAD3. While @value would aim to establish generally applicable lists of values for certain aspects of archival descriptions and would want to predefine these values within the EAS schemas, @normal would be used with regard to standardised (and thereby somewhat "predefined") values from external to the EAS schemas. E.g. if I have a

<persname>
   <part localtype="Vorname">Fjodor</part>
   <part localtype="Patronym">Michailowitsch<part>
   <part localtype="Nachname">Dostojewski</part>
</persname>

in a German EAD3 file, I might want the <persname> to include a @normal="Dostoevskij, Fëdor Michajlovič" along with an @identifier="http://d-nb.info/gnd/118527053" pointing to the controlled vocabulary of the German National Library.

---

That being said: @normal might not be the best name for this purpose, especially as the attribute is also used with a very specific and focused scope in combination with <unitdate>. But that's a conversation for another time...

[fordmadox]

Just a note that since this attribute will have two different controlled-value lists, I think we should consider mentioning that during the call for comments. This is different from how EAD2002 to EAD3 went with the 'type' attribute, where it took one attribute and made multiple attributes for each distinct controlled-value list. I think that I prefer less attribute names (e.g. one 'status' rather than a 'statusX' and a 'statusY'), since attribute have to be associated with elements in XML anyway (where the context is enforced), but just noting the difference here 😄

[fordmadox]

Just a note, as I'm not sure that I've got this right currently, but right now the schemas allow @status in the following elements:

• agencyCode (authorized, alternative)
• otherAgencyCode (authorized, alternative)
• date (ongoing, unknown)
• nameEntry (authorized, alternative)
• fromDate (ongoing, unknown)
• toDate (ongoing, unknown)

[SJagodzinski]

@fordmadox : not in <date>, see #254

[kerstarno]

@fordmadox : not in <date>, see #254

When did we decide not to have @status in <date>? It's listed in the suggested solution here and I can't find anything contrary in the comments. It's also still listed in #179. While the initial question about unknown dates was referring mainly to date ranges, the idea was to treat all "single" date elements, i.e. <fromDate>, <toDate>, and <date> in the same way, wasn't it?