People: Conversion and validation for field 100$d

[alexandermarxen]

The basic idea is to eliminate abbreviations that are only used in people authorities, thereby enabling validation.

The abbreviations for centuries should be implemented as follows:

16.sc 15XX-15XX
18.sc 17XX-17XX

17/18 16XX-17XX
20/21 19XX-20XX

For other abbreviations (c = circa; a = ante; p = post), I would suggest that the content be transferred to field 678 and that c, a or p be eliminated from field 100$d.

* and + (if only a date of birth or date of death is available) should be implemented as follows:

1838* 1838-
1838+ -1838

Subsequently, validation could be introduced:
Only numbers or the letter X may be used.

The implementation for dates before Christ is not entirely clear.
Is 0497-0406 acceptable?
See https://muscat.rism.info/admin/people/437836
cfr.: https://viaf.org/de/viaf/101760867
This would eliminate the possibility of validating the plausibility of the data. (The date of birth should be less than or equal to the date of death.)

[ahankinson]

Since these dates will be used in VIAF and should conform to cataloguing rules, it would be useful to verify them against established headings for similar cases. But in general...

16.sc 15XX-15XX
18.sc 17XX-17XX

In this case the end date is redundant, so "16.sc" would simply be "15XX" since that already covers the dates 1500-1599.

The implementation for dates before Christ is not entirely clear.

All pre-1000 CE dates should have leading zeroes to make them four digits, so 0030-0110.

For BCE dates, it's a bit of a challenge. They should, ideally, have a leading negation sign, but -0497--0406 doesn't work. (EDTF sidesteps this problem by using the / as the date range separator, but I know that's not what we're going for here.)

But you should definitely not simply put a year for BCE dates, since this makes it ambiguous with CE dates. Also, we probably have at least one or two cases where we might want "0010 BCE-0050 CE".

I would say:

• All BCE dates get "BCE"
• If there is no qualifier, then it's assumed to be a CE date
• "CE" can be specified if the date would otherwise be ambiguous.

These dates could still be validated because it would be converted to a negative number -- 0406 BCE is greater than 0497 BCE because -0406 > -0497.

[alexandermarxen]

Although 15XX covers the 16th century, I would find it rather unusual to use it for dates of birth and death, as it would not be user-friendly. In addition, we could make the "-" mandatory, thereby making validation even more efficient. Personally, I would therefore prefer 15XX-15XX.

In the case of BCE, I think the solution is very good. It is clear and can also be validated.

[ahankinson]

In that case I wouldn't try to mix human-readable dates with machine parseable dates. (Note: this doesn't prevent validation, it just means it doesn't conform to a standard like ISO 8601 +EDTF). It seems like you want a nice, user-friendly understandable displays for humans, rather than machine-processable dates.

15XX-15XX is trying to be something it's not, so I think it's better to write "16th c." Here's a possible regex to validate what you have described:

^\s*(?:(?:ca\.?\s*)?0*[1-9]\d*(?:st|nd|rd|th)\s*c\.\s*-\s*(?:ca\.?\s*)?0*[1-9]\d*(?:st|nd|rd|th)\s*c\.|(?:ca\.?\s*)?0*[1-9]\d*(?:st|nd|rd|th)\s*c\.|(?:ca\.?\s*)?\d{4}\s*-\s*(?:ca\.?\s*)?\d{4}|(?:ca\.?\s*)?\d{4}\s*-\s*|-\s*(?:ca\.?\s*)?\d{4}|(?:ca\.?\s*)?\d{4}\s*BCE\s*-\s*(?:ca\.?\s*)?\d{4}\s*(?:BCE|CE))\s*$

Valid dates with this regex:

0100 BCE-0030 BCE
0010 BCE-0020 CE
ca. 1345-
1345-
1450-ca. 1555
ca. 1876-ca. 1901
-ca. 1678
1900-1944
16th c.
1st c.
03rd c.
ca. 14th c.
03rd c.-04th c.
ca. 15th c.-ca 16th c.

Invalid dates:

15.sc
-1445+
1344*-1345+
123-456
-1923 a.C.

Muscat can show a big red flag if any of the invalid dates are input. The only thing it won't do is validate whether the first date is less than the second date, but that can't be done with regex anyway.

NB: In RISM Online we can still turn these dates into valid machine-processed date ranges, and validate the beginning is less than the end! It's just there's an extra (automated) step involved.