<unitDate> needs an attribute for normalised dates

kerstarno commented 5 months ago

Creator of issue

Kerstin Arnold
TS-EAS EAD team lead
@kerstarno
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

Reporting a bug

Text: While adapting an EAD 2002 file to EAD 4.0, I found that - with the removal of @normal - the element <unitDate> is currently missing an attribute to encode a normalised form of the date.

Suggested Solution

Text: Rather than re-introducing @normal only for this specific use case, I suggest adding @standardDate. As we have opened up the encoding of normalised dates to other standards than ISO 8601, the data type of @standardDate also allows for the inclusion of normalised date ranges, i.e. the attribute isn't bound to only single dates anymore. While <unitDate> in itself can also include date ranges or date sets, I suggest applying the "attribute-group.standard-date-attributes.optional" to it, which would - next to @standardDate also add @notAfter and @notBefore, which I think could be useful for encoding dates of creation as well. Similarly, it might be useful to also have @status available.

kerstarno commented 5 months ago

To be discussed at the next EAD team meeting on 23 February. However, I've created a new branch to take care of this change already (https://github.com/SAA-SDT/eas-schemas/tree/exampleFileIssues) to speed up the implementation process and update before the call for comments, provided the EAD team approves.

fordmadox commented 5 months ago

My thoughts remain the same: we should not keep both <unitDate> and <unitDateStructured>. What's the point of providing a choice when both can contain a text node, and both have optional attributes to encode "machine-readable" dates? In other words, I definitely think is one of those areas where if we currently don't simplify the encodings even though we could; we are missing an opportunity to respond to feedback + adhere to our own general guidelines.

MicheleCombs commented 5 months ago

+1 to Mark’s summary. (I would vote for going with the simpler .)

Michele

kerstarno commented 5 months ago

Thank you, both. Note taken. This will certainly help in preparing this issue for the discussion at the EAD team meeting on 23 February.

I also did a quick search in the EAD3 repository and found:

from the revision period of EAD3 (all dating from 2012 and 2013).

@fordmadox - if you know of any other feedback re only retaining either <unitDate> or <unitDateStructured>, which was received after the release of EAD3, could you point me towards that, please?

Last: it might be worth noting as well, that RiC has now removed the sub-entities single date, date range and date set, and only works with one date entity.

kerstarno commented 4 months ago

The EAD team discussed this issue during their meeting on 23 February and, while there were some arguments in favour of focussing on just the simple <unitDate>, decided to keep both parallel options in the EAD 4.0 draft schema for the time being. It also was decided to ask the community for feedback on this question specifically as part of the call for comments and the engagement activities that will be held during that period.

In terms of the initial change reported in this issue, the EAD team agreed to have @standardDate added to <unitDate> along with @notAfter, @notBefore, and @status.

Furthermore, the team spoke about the way dates are defined in RiC, where they include a date type attribute, a date qualifier (regarding certainty), an expressed date (date in natural language, repeatable) and a normalised date. With @unitDateType and @certainty the first two are also available already with <unitDate> and adding @standardDate not only allows for the encoding of a normalised date, but also extends the expression of certainty respectively uncertainty with the option of qualifiers from EDTF. The expressed date could be understood as what's currently encoded in the <unitDate> element itself, even though the current approach of the EAS in general is slightly different from the approach of RiC.

In short:

[x] Add @standardDate, @notAfter, @notBefore and @status to

See pull request https://github.com/SAA-SDT/eas-schemas/pull/95

kerstarno commented 3 months ago

Tested with the XSD and the RNG and can confirm that <unitDate> now includes @standardDate, @notAfter, @notBefore, and @status.

Schema-wise this seems resolved, though there remains an issue with regard to the Schematron validation re the values of @standardDate, @notAfter, @notBefore in <unitDate> compared to the other (single) date elements (see https://github.com/SAA-SDT/eas-schematrons/issues/7).

fordmadox commented 3 months ago

@kerstarno : I've started to make those updates for the schematron, but I haven't finished yet (see https://github.com/SAA-SDT/eas-schematrons/commits/issue_7/). I'm aiming to have that done before your day tomorrow, though.

SAA-SDT / eas-schemas