[Historic] Temporal Tagging

[Rob Warren]

Brad,

I've done some work on the topic myself on the linked open data side  
[1]. My conclusions are similar to yours: there are three different  
types of information: The Thing, the Name of the Thing and the  
Location of the Thing and all three are not the same Thing.

It is probably in our interest not to make too many changes to the OSM  
XML specs; perhaps we can achieve everything by simply adding  
start_date/end_date to features, ways, nodes and tags? I can't think  
of a case where change could not be encoded using this approach.

There is the question of imprecise dates (which really aren't all that  
different from having a precise date with no time). I'd suggest that  
this be handled by the renderer: most people visualize a year or era,  
finding features is a query based on date overlap. My only addition  
would be the before or after tags that would account for "I know it  
used to be call Signal Hill but I don't remember when".

You might mean probability in your example instead of confidence  
factor, but my concern with both is that they mean essentially nothing  
unless you know exactly what process generated the numbers; I'm not  
sure what I would do with a tag that said "There is a 45% chance that  
this is the grave of XYZ".

Perhaps your Signal Hill example is not the best for confidence factor  
in that toponymy is primarily a cultural artifact; I can think of  
several features that appear under different names depending on the  
institution that produced the map. The solution to that is the  
creative use of the source tag, which in the end is no different that  
the language tag for this particular case.

I am working on another project where documenting a confidence factor  
would be useful in that location is estimated statistically from the  
reported sinking locations of ships. The wreck location is predicted  
to be within a polygon with a .95 confidence interval, which is much  
more useful that a single node when trying to figure out whether an  
anchor is likely to foul at that location. Still for most people, or a  
renderer, the statistical information is unlikely to be useful without  
a reference to a description of how it was achieved and documenting  
that seems complex.

Does OSM have a tag to record Feature A is part of Feature B?

best,
rhw
[1] http://rdf.muninn-project.org/ontologies/graves.html

On 21-Jan-13, at 8:33 PM, historic-request at openstreetmap.org wrote:

> Message: 4
> Date: Mon, 21 Jan 2013 17:32:44 -0800
> From: Brad Thompson <brad at pastmapper.com>
> Subject: Re: [Historic] Temporal Tagging
>
>
> The issue of how to handle changes in names, locations, and shapes  
> (for
> territories, building footprints, etc) has been a favorite topic of  
> mine in
> a few discussions to date. The problems can quickly become complex,  
> but I
> think a simple schema could encompass all possible historical  
> scenarios.
> I'm happy to share the observations / conclusions, which have  
> generally
> been the following:
>
> 1) Unlimited Changes to All Attributes: The schema should allow the
> recording of an *unlimited* number of changes to *any* attribute of  
> any
> entity. No attribute can be used as a unique identifier, like 'name'  
> or
> 'address' or even location-based attributes, because throughout  
> history,
> all of these things can change. Therefore, a truly unique identifier  
> must
> be assigned to each entity. Additionally, buildings are moved,  
> streets are
> renamed, rerouted, and renumbered. Tim, as you've pointed out, this  
> has
> happened many times to some entities. Therefore, a schema that simply
> allows for a single 'old-name' isn't flexible enough. All changes to
> attributes as described above must each have a time associated with  
> them.
> 2) Confidence Factors: Because historical data inherently entail
> uncertainty, there should be a method of assigning a confidence  
> factor to
> any attribute. (This feature has no purpose in realtime mapping,  
> because
> all data can be verified against actual conditions.) This confidence  
> factor
> would be applicable both to attributes like names as well as times.  
> For
> names, for example, "we think the name of this hill was Telegraph  
> Hill, but
> there are conflicting reports that claim it was called Signal Hill,  
> so we
> assign a 60% confidence factor to Telegraph Hill and a 40% confidence
> factor to Signal Hill". The renderer could then decide how to  
> display the
> name(s). For times, for example, "we know this hill changed name  
> from Loma
> Alta to Telegraph HIll sometime between 1848 and 1852, but we don't  
> know
> for certain when, so we assign the date of the change as January 1,  
> 1850
> and give it a confidence factor of 4 years (creating a buffer with a
> temporal diameter of 4 years around that date). This idea is critical,
> because it allows conflicting reports and developing research to be
> displayed alongside well-established facts.
> 3) Spatial and Non-Spatial Entities: Because shapes (nodes, etc.)  
> cannot be
> used as unique identifiers the way they can for realtime mapping,  
> there
> exists a need to create a distinction between spatial entities and
> non-spatial entities. This way, each spatial permutation (or  
> version) of an
> entity, like a building or a road or a territorial boundary, can  
> have a
> distinct shape that is still linked to the nonspatial entity that
> represents the concept of its agreed-upon identity. For example,  
> 'United
> States of America' would be a nonspatial entity with a start date of  
> 1776
> and no end date. But linked to that entity would be dozens of spatial
> entities, because the boundaries of the United States have changed  
> dozens
> of times, therefore changing the shape, through small border edits or
> territorial acquisitions. Each of those shapes would have its own  
> start and
> end time, and the map would display the correct shape as determined  
> by the
> time being viewed.
>
> Obviously, we're talking about a dramatically different way of  
> recording
> place data, but in my view, these levels of detail are critical to  
> making a
> viable historical mapping platform where multiple types of data can be
> shared and displayed. Looking forward to hearing everyone else's  
> thoughts
> on this.
>
> Brad Thompson
> Pastmapper