[Historic] The "time" of time

Aaron Straup Cope aaronofmontreal at gmail.com
Thu Aug 30 11:51:13 BST 2012


Ooh!

How does one add eras and/or is there a list of the complete set? Poking 
around the API it doesn't seem like there are that many entries.

On 8/29/12 12:30 PM, Sean Gillies wrote:
> Aaron, have you ever seen the Common Eras project?
>
>    http://commoneras.ecs.soton.ac.uk/category/Doctor%20Who.html
>
> Leif might be lurking on this list for all I know. He and I have been
> talking with a few other programmers in the
> classics/byzantine/medievalist fields about expanding on this concept
> to make something might suit us better than existing controlled
> vocabularies. It gets interesting where otherwise solid chronologies
> start to float loose from known dates (Ancient Egyptian Kingdoms, for
> example) or where researchers dispute the beginnings and endings of
> cultural periods.
>
> On Sat, Aug 25, 2012 at 7:03 PM, Aaron Straup Cope
> <aaronofmontreal at gmail.com>  wrote:
>> Ah, interesting. I didn't realize that ISO 8601 supported BCE.
>>
>> Also, if it wasn't clear: I meant that you'd (almost) always end up with
>> both a start date and an end date. This is fairly common for museums.
>>
>> It's just that we get to try and teach computers to make sense of random
>> human-strings at both end of the range. Random stuff like:
>>
>> "c. 12th century to late industrial revolution"
>>
>> Which is super interesting because there are in fact three date ranges
>> happening here.
>>
>> So as much as anything we need to find a way for museum folks (institutions)
>> to define canned ranges for "c. 12th century" – because remember the
>> granularity has capital-M meaning in many cases – as it is to denote the
>> possible span of two ranges.
>>
>> This ends up meaning you store a bunch more fields potentially but, modulo
>> the part where it's all still hand-waving, if we can boil it all down to
>> (signed) numbers then there's a portability to the data that isn't bound to
>> any given database implementation (for date math).
>>
>>
>>
>> On 8/25/12 6:08 PM, Dan Vanderkam wrote:
>>>
>>> It looks like ISO-8601 does support BCE: you'd encode the date as
>>> something like "-0002-12-25".
>>> http://en.wikipedia.org/wiki/ISO_8601#Years
>>>
>>> There are also some interesting questions here about whether you use
>>> the Gregorian calendar before the was a Gregorian calendar, or the
>>> Julian calendar before there was a Julian calendar. ISO-8601 uses the
>>> "proleptic Gregorian" calendar, and that seems like a reasonable
>>> choice.
>>>
>>> An alternative to storing (timestamp, granularity) would be to store
>>> an (earliest possible timestamp, latest possible timestamp) pair. I
>>> used this format in OldSF and found it quite handy. There were many
>>> photos which had only a year, or a range of years, or just a decade.
>>> The pair of timestamps lets you encode this precisely without worrying
>>> too much about what the granularity field really means.
>>>
>>>     - dan
>>>
>>> On Sun, Aug 26, 2012 at 12:58 AM, Aaron Straup Cope
>>> <aaronofmontreal at gmail.com>   wrote:
>>>>
>>>> One of the things that a few of us in the museum world have been talking
>>>> about is boiling any given date in to 4-5 individual fields:
>>>>
>>>> * A display date, like "c. 12c crazy times"
>>>>
>>>> * An ISO-8601 date string
>>>>
>>>> * A boolean indicating BCE
>>>>
>>>> * A granularity, which is little more than a label/pointer to a function
>>>> that calculates a date range for a starting (ISO-8601 + is_bce).
>>>>
>>>> Flickr used "granularities" to express month, year, decade and eventually
>>>> circa for photos in the Commons. Circa was simply decided from on high
>>>> (read: me) to mean 5 years on either side of a date but you could make
>>>> the
>>>> rules governing date in and dates out as complex as you wanted. They just
>>>> need to be documented somewhere.
>>>>
>>>> * A function for encoding/decoding one end of granulatity(iso8601, isbce)
>>>> as
>>>> a signed (big) int for storing the above as plain numbers for doing fast
>>>> date ranges in a database. The idea is that 0 would continue to mean Jan
>>>> 1
>>>> 1970 and that anything before it would become a negative number.
>>>>
>>>> An added bonus would be something that could take (iso8601, bce,
>>>> granularity) and pre-generate as good a display date as possible.
>>>>
>>>> It's still mostly talk although the talk has started to include words
>>>> about
>>>> grant money to find someone to do the encoding/decoding. The last thing I
>>>> want to do (or can) is suffer that kind of date math.
>>>>
>>>> But it would be super useful across a range of fields, I think.
>>>>
>>>>
>>>>
>>>>
>>>> On 8/24/12 12:28 PM, Jeff Meyer wrote:
>>>>>
>>>>>
>>>>> Mikel's spherical Mercator thread triggered another question for me - if
>>>>> we were to add the concept of time to any map-/geo-related objects, how
>>>>> would we express that time?
>>>>>
>>>>> Does anyone have a recommendation for this?
>>>>>
>>>>> ISO-8601 is often referenced (and maligned) as the relevant standard,
>>>>> begging the questions:
>>>>> - Which ISO-8601?
>>>>> - How to handle BC / negative years?
>>>>> - Why use such an odd convention (YYYY-MMM-DD... big Endian?)?
>>>>>
>>>>> I believe the OpenLayer guys have run into some interesting challenges
>>>>> working with this format.
>>>>>
>>>>> - Jeff
>>>>>
>>>>> https://github.com/openlayers/openlayers/pull/413
>>>>>
>>>>> --
>>>>> Jeff Meyer
>>>>> Global World History Atlas
>>>>> www.gwhat.org<http://www.gwhat.org>
>>>>> jeff at gwhat.org<mailto:jeff at gwhat.org>
>>>>> 206-676-2347
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Historic mailing list
>>>>> Historic at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/historic
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Historic mailing list
>>>> Historic at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/historic
>>>
>>>
>>
>>
>> _______________________________________________
>> Historic mailing list
>> Historic at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/historic
>
>
>




More information about the Historic mailing list