2024-10-24 discuss historic calendar conversion & undate logic

[rlskoeser]

meeting with @rlskoeser and @robcast to discuss calendar conversion should be integrated into undate

Discussion based on work with Islamic Scientific Manuscripts (ISMI, @robcast ) and Princeton Geniza Project (PGP, @rlskoeser )

Hijri dates have multiple challenges:

• conversion between calendars
• representation of dates

are converted dates different than formatted/parsed dates?

• important to keep label and original calendar
• there's potential slippage when round-trip converting between calendars
• historically Hijri dates depended on when the new moon was sighted, possibly much more ambiguous than we might expect

calendar as an internal indicator - if you output a converted date in the original calendar, should not have any conversion errors

internally you need a standard calendar for computation/comparison

In @robcast ISMI database, dates are represented in rdf / cidoc-crm

• workaround to use appellation / name of date - text version in original calendar; corresponds to our label in undate
• give it an input type to specify the calendar
• primitive date object is always gregorian

cidoc-crm always has a timespan (earliest / latest) or occurred at some point within a range

this is implemented in research space - django, some java server side, lots of sparql

• define fields, define how they get reformatted into rdf triples

ISMI editing interface

• date picker js library includes calendar conversion
• label, type, year
  react-date-object
  • supports gregorian, persian, arabic, indian calendars
  • part of react-multi-date-picker
    • Robert hacked together and submitted a julian calendar but doesn't work for all days, library is undocumented, something went wrong (negative years in some cases)

add original calendar

• decide / document what is used internally for calculations (~ gregorian)

does it make sense for calendar conversion to be a "formatter" ?

• maybe rename all of these to call them converters? (could use "transformer" but that's kind of a loaded term)
  • on first glance, would assume that formatter outputs text; converter is potentially broader
  • e.g. CIDOC-CRM would be an RDF object rather than text

it would be useful to come up with a generalized approach for operationalizing related/inferred dates

• based on connected people, places, other factors (mentioned coins, historical place names)
• relevant for both ISMI and Princeton Geniza Project

could make switch between julian/gregorian depending on context

• even hijri dates very much tied to cycle, leadership

CIDOC-CRM converter/formatter could be useful; make Robert's solution for converted dates more standard; could make rdflib an optional dependency

next steps:

• @rlskoeser create new issues or update existing issues based on decisions from this discussion
• @robcast updated ISMI example data with more recent version (see complex date objects from the ISMI database #17 )
• @rlskoeser implement preliminary calendar conversion as a date converter/formatter (probably Hijri since common to our two projects)
• once we have sample data and preliminary conversion logic: @robcast and @rlskoeser work together on an example notebook to compare date conversion logic used in ISMI with date conversion logic in undate

[robcast]

Regarding conversion uncertainty, I just found this short description of the complications of converting historical Hijri calendar dates: https://www.gautschy.ch/~rita/archast/mond/arabcal.html (also the islamic day starts and ends at sunset)