Closed atomrab closed 4 years ago
Do we have some data for this? Adding the new fields to the database will be straightforward - what about populating them?
We do have some basic dating in the write ups of the small finds that have already been generated. I’ll have to put this all in manually, but since only about a fifth of the finds (or fewer) are likely to be datable, this shouldn’t be too burdensome.
On Thu, Aug 27, 2020 at 9:06 AM Mike Johnson notifications@github.com wrote:
Do we have some data for this? Adding the new fields to the database will be straightforward - what about populating them?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atomrab/chersark/issues/11#issuecomment-681971443, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEFPA52Z4QMD43GPYZFSITSCZR75ANCNFSM4P3Q67NQ .
I have added these fields, it expects the year as AD, so -150 will be 150BC, 300 will be 300AD.
Let me know if this is OK
Could we use the ISO8601 spec with year zero instead, to match PeriodO? That would mean four digits (including leading zeros) and 150 BC is -0149.
On Thu, Aug 27, 2020 at 2:00 PM Mike Johnson notifications@github.com wrote:
I have added these fields, it expects the year as AD, so -150 will be 150BC, 300 will be 300AD.
Let me know if this is OK
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atomrab/chersark/issues/11#issuecomment-682134122, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEFPA4J5DC2NAIZWJY6U73SC2UNXANCNFSM4P3Q67NQ .
Hmm, this seems trickier than I hoped - I have changed these dates to be stored as numbers, and specified the spec in the suffix - I think this is the best we can do.
As long as the JSON context indicates that this is the format of those fields in the serialization, I think we’re fine. That shouldn’t be too tricky, right?
On Fri, Aug 28, 2020 at 3:14 AM Mike Johnson notifications@github.com wrote:
Hmm, this seems trickier than I hoped - I have changed these dates to be stored as numbers, and specified the spec in the suffix - I think this is the best we can do.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atomrab/chersark/issues/11#issuecomment-682393092, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEFPA6KWA2QS6NCH72OKADSC5RM3ANCNFSM4P3Q67NQ .
From email to @MikeJJohnson on July 27, 2020: "I have been looking at small finds, to which periods can be assigned. In many cases, this will be all we can tell, but in some other cases we can provide more precise dating either from associated objects or from comparanda. Would it be impossible to add start/end ISO date fields to the small find module, and to the input form? I ask mainly because I feel like this could facilitate the work that we've been discussing in relation to temporal logic (if we can export the context periodizations and phasing, the small find periodization and dates, and the narrative text from the notebooks, I feel like we might be able to do something quite interesting, computationally). But if it's too much work, it's not a priority."
The best would be four-part ISO8601 Gregorian year dates: earliestStart, latestStart, earliestEnd, latestEnd.