2024-10-24 discuss historic calendar conversion & undate logic #95
rlskoeser
started this conversation in
Meeting notes
Replies: 1 comment
-
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) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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:
are converted dates different than formatted/parsed dates?
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
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
ISMI editing interface
react-date-object
add original calendar
does it make sense for calendar conversion to be a "formatter" ?
it would be useful to come up with a generalized approach for operationalizing related/inferred dates
could make switch between julian/gregorian depending on context
CIDOC-CRM converter/formatter could be useful; make Robert's solution for converted dates more standard; could make rdflib an optional dependency
next steps:
Beta Was this translation helpful? Give feedback.
All reactions