<date>

[SJagodzinski]

Date

• add optional attributes:
  @audience
@calendar
@certainty
@conventationDeclarationReference
@era
@localTypeDeclarationReference
@maintenanceEventReference
@scriptOfElement
@sourceReference
• keep name and scope
• topic for Best Practise Guide

Creator of issue

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

Related issues / documents

Topic_dates_20200911.pdf
<date>: add @certainty #75
<date>: best practice #34
New attribute @status #70

EAD3 Reconciliation

Additional EAD 3 attributes:
@altrender - Optional
@audience - Optional (values limited to: external, internal)
@calendar - Optional
@certainty - Optional
@encodinganalog - Optional
@era - Optional
@normal - Optional
@script - Optional

Context

Summary: The single date of an event in the history of, or a relationship with, the person, family, or corporate body being described in the EAC-CPF instance.
May contain: [text]
May occur within: chronItem, cpfRelation, dateSet, existDates, function, functionRelation, legalStatus, localControl, localDescription, mandate, occupation, place, resourceRelation, useDates
Attributes: @localType, @notAfter, @notBefore, @standardDate, @xml:id, @xml:lang - all optional
Availability: Optional, Repeatable

Solution documentation:

May contain: [text]
May occur within: chronItem, dateSet, existDates, function, legalStatus, localControl, localDescription, mandate, occupation, place, useDates
Attributes:
@audience - optional (values limited to: external, internal)
@calendar - optional
@certainty - optional
@conventationDeclarationReference - optional
@era - optional
@id - optional
@languageOfElement - optional
@localType - optional
@localTypeDeclarationReference - optional
@maintenanceEventReference - optional
@notAfter - optional
@notBefore - optional
@scriptOfElement - optional
@standardDate - optional
@sourceReference - optional
Availability: Optional, Repeatable

• New or other example needed
• Topic for Best Practise Guide

Example encoding

<localControl>
 <term>term for local control</term>
 <date audience="external" certainty="circa" conventionDeclarationReference="conventiondeclaration1" id="date1" languageOfElement="en" localType="localDate1" localTypeDeclarationReference="localTypeDeclaration1" maintenanceEventReference="maintenancevent1" notAfter="2020" notBefore="2010" scriptOfElement="lat" sourceReference="source1" standardDate="2015">date of local control</date>
</localControl>

[ailie-s]

Draft Tag Library Text:

Summary: The single date of an event in the history of the person, family, or corporate body being described in the EAC-CPF instance.
May contain: [text]
May occur within: chronItem, dateSet, existDates, function, legalStatus, localControl, localDescription, mandate, occupation, otherEntityType, place, relation, useDates
Attributes:
@audience - optional (values limited to: external, internal)
@calendar - optional
@certainty - optional
@conventationDeclarationReference - optional
@era - optional
@id - optional
@languageOfElement - optional
@localType - optional
@localTypeDeclarationReference - optional
@maintenanceEventReference - optional
@notAfter - optional
@notBefore - optional
@scriptOfElement - optional
@standardDate - optional
@sourceReference - optional
@target - optional
Description and Usage:
An element for expressing the single date of an event in the history of the person, corporate body or family being described in the EAC-CPF instance.
The content of the element is intended to be a human-readable natural language date with a machine-readable date provided as the value of the @standardDate attribute, formulated according to ISO 8601.
If the event or relationship has inclusive dates use the <dateRange> element, while more complex dates (combining singles dates and date ranges) can be expressed in <dateSet>.
Dates of existence for the entity being described in the EAC-CPF instance are encoded with the <existDates> element, while the dates of use of a particular name of an entity are encoded in <useDates>. The date and time of a maintenance event in the history of the EAC-CPF instance are given in the <eventDateTime> element.
Attribute Usage:
Use @certainty to indicate the degree of precision in the dating, for example, "circa," "approximately," or "after."
Use @localtype to supply a more specific characterization of the date.
Use @notAfter and @notBefore to capture the earliest and latest possible dates in machine-processable form in cases when the date is uncertain.
Use @standarddate to provide a machine-processable form of the date.
Availability:
Within <function>, <legalStatus>, <localDescription>, <mandate>, <occupation>, <otherEntityType>, <place>, <relation>: one of <date>, <dateRange> or <dateSet> optional, not repeatable
Within <existDates> and <useDates>: one of <date>, <dateRange> or <dateSet> required, not repeatable
Within <dateSet>: at least two of <date> and/or <dateRange> required, repeatable
Within <chronItem>: one of <date> or <dateRange> required, not repeatable
Within <localControl>: one of <dateRange> or <date> optional, not repeatable

[SJagodzinski]

No @status attribute for <date>.

@ailie-s

I saw @status being useful for date ranges that are incomplete, which doesn’t apply to <date>. status=”ongoing” doesn’t make sense for <date>. Allowing status=”unknown” on <date> could mean that elements that require a child date element don’t include date data, which would not be ideal. Unless there are some use cases I haven’t thought of, I think we should not include @status on <date>.

[kerstarno]

Sorry, but the same (i.e. required date element with no actual date data) can be said in case someone uses <dateRange> with <fromDate status="unknown"/> without adding <toDate> or even when adding <toDate status="ongoing"/>.

Seeing that we're now removing the option "ongoing" for <fromDate> and are keeping it with "unknown" only (see #254), I think the same should apply to <date> in order to at least treat the single date elements (i.e. <date>, <fromDate>, and <toDate>) more or less in the same way. Otherwise, we'd have one with two values for @status, one with only one value for @status and the third with no @status at all.

[SJagodzinski]

Otherwise, we'd have one with two values for @status, one with only one value for @status and the third with no @status at all.

And this approach would make sense. How to explain <date status="ongoing"> when treating all date elements the same way? Only useful value would be <date status="unknown"/> for a complete unknown date. In this case, the date element should be allowed to be empty.

[kerstarno]

I didn't mean to suggest we should keep <date status="ongoing"/> after we've removed it from <fromDate>, but I suggested to apply the same approach to <date> as was now decided for <fromDate>, i.e. at least allowing <date status="unknown"/>. And: all three single date elements already are allowed to be empty anyway.

[kerstarno]

Tested as part of Schema Team's schema testing:

• <date> is a sub-element of <dateSet>, <localControl>, <useDates>, <otherEntityType> (see <otherEntityType> #142), <function>, <legalStatus>, <localDescription>, <mandate>, <occupation>, <place>, <existDates>, <chronItem>, and <relation> (see <relation> #214)
  • @ailie-s The TL draft above is currently missing <otherEntityType> and <relation> as potential parent elements to <date>
• <date> in itself is optional in all its contexts, but one of <date>, <dateRange> or <dateSet> is required in the contexts of <useDates> and <existDates>, while (at least) one of <date> or <dateRange> is required in the contexts of <dateSet> and <chronItem>
• <date> is only repeatable in the context of <dateSet>
• <date> can contain text
• <date> allows for the optional attributes @audience, @id, @target, @languageOfElement, @scriptOfElement, @conventionDeclarationReference, @maintenanceEventReference, @sourceReference, @localType, @localTypeDeclarationReference, @calendar, @era, @certainty, @notBefore, @notAfter, and @standardDate
  • @status has already been removed from the draft schema, but it is still mentioned in the draft TL above (attributes list and section on attributes usage) - final decision pending
• <date> also allows for optional attributes from other namespaces (tested with XLink)

The above applies to both schemas, RNG and XSD.

[kerstarno]

With the decision in #254 to not (re-)enable @status="unknown" in <date>, this element is ready.

[kerstarno]

Following their meeting on 18 June, the EAD team would like to suggest that @status is added to <date> as well, allowing the value "unknown" (i.e. the same as <fromDate>. The main use case behind this is the use of <date> as one of the possible sub-elements of <unitDateStructured>, where having an "unknown" status could help clarify cases of "no date"/"n.d." etc. which are relatively common when describing archival material.

[SJagodzinski]

EAC-CPF meeting 3 September 2021:

Decision: add the optional @status attribute to <date>, with a single option: “unknown”

[SJagodzinski]

@fordmadox : Seems that @status hasn't not yet included in schema yet

See #179 (comment)

[fordmadox]

Thanks for the reminder, @SJagodzinski! I just updated that. @kerstarno already removed the Tested by Schema Team label, so we'll test again with the final release next month. Should be good to go now in the 'development' branch, though.

[kerstarno]

Re-tested with the XSD and RNG schemas available in the development branch (status of 8 January 2022).

I can confirm that @status with the (only) value "unknown" has been included for <date> in both schemas.