[Historic] The "time" of time

Brad Thompson brad at pastmapper.com
Thu Aug 30 02:04:51 BST 2012


So glad to be having this conversation! I've been out of the country, so
I'm late to this chat, but a brief intro to me - I'm the creator of
Pastmapper, and through it I've been fortunate to meet Dan and Jeff and a
number of other people working in this space. My goal is to create a
platform for historical mapping, and a centralized method of organizing and
georectifying old maps to create a visually unified view of space over time
(Google Maps for the past, with the appropriate creation tools). Ultimately
I'm excited about an accurate base map that can be made available to anyone
wanting to display historical information on a map.

On the 'time of time' topic: I think ISO 8601 is a suitable standard to use
as a basis (it allows a standard for describing durations, allows very
granular time intervals, etc), but that two modifications would be
necessary to make it useful within a historical mapping platform:

1) Degree of confidence (as discussed already on this thread), to allow
quantification of what 'circa' means for a particular item. One simple (too
simple?) method might be to store two values for each Start and End field:
the timestamp value and a confidence value, both  stored using ISO 8601
markup. The 8601 standard allows durations to be described independent of a
date, so the confidence value, like a temporal pixel (a tempel?) would
refer to an amount of time. In other words, a small value would indicate
high confidence and a large value would indicate lower confidence. For
example, the entry for the Challenger explosion would have very small
tempels for both Start and End timestamps, possibly as small as a few
milliseconds, whereas the entry for Stonehenge would have a Start timestamp
with a large tempel, measured perhaps in a few hundred years. Aaron, how
would something like that line up with what you discussed?

2) Correlation between the ISO 8601 standard (aka today's Gregorian basis)
with other calendar systems. Throughout history, great variations in
calendaring systems, sometimes with highly localized discrepancies, have
existed. A useful historical platform would be flexible enough to indicate
these, and to translate between systems in the same way that place labels
can be localized by language. One crazy example from the Julian-Gregorian
switchover is Sweden, which chose to adopt the Gregorian calendar over a
period of 40 years, by skipping all leap years between 1700 and 1740. But
by accident, they observed leap years anyway in 1704 and 1708, then decided
in 1712 to revert back to the Julian calendar, and added days in February
to make up the discrepancy. In roadmapping Pastmapper, I've used this
example to demonstrate the need for all of the entries called 'Sweden'
during these years to be associated with the appropriate calendar variants,
so that February 30, 1712 can be shown to have existed in Sweden but not in
Norway. This would be manifested in Pastmapper by presenting a user viewing
a map of this era and region with a time slider for the 'expected'
Gregorian calendar (ISO 8061) and an optional one using the Observed Local
calendar.

This is how I've envisaged the issue for my project, but I'm very curious
about other perspectives, problems, alternatives, etc.

- Brad

On Sun, Aug 26, 2012 at 4:00 AM, <historic-request at openstreetmap.org> wrote:

> Send Historic mailing list submissions to
>         historic at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openstreetmap.org/listinfo/historic
> or, via email, send a message with subject or body 'help' to
>         historic-request at openstreetmap.org
>
> You can reach the person managing the list at
>         historic-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Historic digest..."
>
>
> Today's Topics:
>
>    1. Re: The "time" of time (Aaron Straup Cope)
>    2. Re: The "time" of time (Dan Vanderkam)
>    3. Re: The "time" of time (Aaron Straup Cope)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 25 Aug 2012 17:58:59 -0400
> From: Aaron Straup Cope <aaronofmontreal at gmail.com>
> To: historic at openstreetmap.org
> Subject: Re: [Historic] The "time" of time
> Message-ID: <50394AA3.7000204 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 26 Aug 2012 01:08:03 +0300
> From: Dan Vanderkam <danvdk at gmail.com>
> To: aaronofmontreal at gmail.com
> Cc: historic at openstreetmap.org
> Subject: Re: [Historic] The "time" of time
> Message-ID:
>         <
> CAGiBXrwJy803kzvxU8tJPaajM+BOphoZUFON4UK59+COMeTgYw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 25 Aug 2012 21:03:48 -0400
> From: Aaron Straup Cope <aaronofmontreal at gmail.com>
> To: historic at openstreetmap.org
> Subject: Re: [Historic] The "time" of time
> Message-ID: <503975F4.1030303 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> 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
>
>
> End of Historic Digest, Vol 1, Issue 7
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20120829/e12721bd/attachment-0001.html>


More information about the Historic mailing list