Matthäus Seutter, Le plan de Paris, ses faubourgs et ses environ, 1720.
Matthäus Seutter, Le plan de Paris, ses faubourgs et ses environ, 1720.

Exists

We had to figure out how to handle cities, buildings, and streets where we don't know the date when they were built. Our approach is that our historical data set should include only real data that can be cited. We created the "exists" factoid to better represents the temporal uncertainty inherent in the data and to provide a clearer and more verifiable citation.

Temporal Uncertainty

Running Reality is really a world history model, not a map. It's native language is history, not geography, even though most of what you see is a map. Its core data structure is the timeline, not the polygon. We believe it is critical to model historical data in a format that is native to historical data. We do not believe in forcing the data to adapt to the engine. Further, if you are representing history data natively, temporal uncertainty is critical to model. Here are some examples of historical data:

Running Reality does not require precise dates for its data, but this kind of data requires a more fundamental approach than just allowing uncertain dates. We have a fairly precise date: the Seutter map is from 1720. The problem is that this data does not indicate when it was built. What we do know from the cited reference work is that the object exists on this date.

Behind the scenes, Running Reality is history engine that is more like a system dynamics simulation. Factoids are actually like programming instructions to the history engine to tell it how to best represent history. What we want to tell this engine is what we know, nothing more and nothing less. That way our factoid data set is just what is known, what is verifiable, and what is auditable. Importantly, we also want to be able to tell the engine what we know now but keep our options open to give it more precise information later when we have more research in hand or other researchers have brought more data to light. The engine is authorized to make specific inferences to interpolate or extrapolate from the factoid data, as needed for the visualization engine. If you know the engine's inference is incorrect, then that probably means that you have additional research that can be provided as data to the engine.

GIS If you are coming from a GIS background, this approach can feel a bit strange. In a GIS system, the data is geographic, with time data handled as metadata. Running Reality treats time data as the primary data. Every object has a timeline as its primary data structure, with geographic and other kinds of data then attached to that timeline.

Event versus Data Factoids

Very often we don't know the date of an event, like a building build date or a city founding date. In such cases, we use an exists data factoid. As a data factoid, it asserts something is true on the date of the factoid while leaving to the history engine the role of interpolating or extrapolating. If you have this 1720 map of Paris and it shows a building, mark that it exists in 1720, and use this map as your citation. The building will then appear on the map in roughly the correct years, and it will definitely appear on the map in the years it is definitely known to exist. This also leaves more room for additional research. If someone does more detailed research later, they can add the built date if it is known without having to delete any data. Usually the research effort required to identify a building as existing on a date is much less than finding the built date. Existence can be determined from a map, a traveler's report, or carbon dating. A built date might come from a government record, a leader's proclamation (if a particularly famous building), or other record. For cities, even declared "founding dates" are often not the real founding dates. Often they are a re-dedication where a leader "founds" a city on the site of an existing town. It is all too common to read, "This year, further excavation of the next soil layer revealed artifacts that indicated the site was occupied as early as 1200BC."

FUTURE We are working on creating a "does not exist" factoid as well, so you can report that the building shown on the 1720 map was also not shown on a second 1690 map. that would narrow the range for when the building was built, improving the engine's inference, and staying close to the true nature of the evidence.

This extends to conditions as well. If you know the date when a building was abandoned or ruined, such as the date of an earthquake, then use an abandoned event. Otherwise, if you only know that the building was abandoned in 1400 but not the exact date, then add a structure factoid for condition = abandoned on 1400. Event factoids versus data factoids will result in the engine using different interpolation / extrapolation rules for the timeline of this condition.

If we "know" a building was abandoned sometime in the 14th century, a basic approach is to try to model this as an abandoned event in 1350 with an uncertainty of 50 years. However, that "knowledge" is very often a human inference, not data. What we usually really know is that the building was in use around 1300 (e.g. maybe due to a coin or pottery) and abandoned by 1400 (e.g. dating of soil on the floor or a written text by a traveler). If possible, it is usually better to record the direct evidence of a building's condition on known dates and then let the Running Reality engine do the interpolation. That way the inference is explicitly done by the engine and not baked into the data set. Far too often, baking in such an inference leads to having to delete that factoid later because someone just found a reference to the building being in use in 1310.

We also use these same concepts for how to handle the complexities of an object persisting over extended periods of time. Cities never fully go away, leaving remains long after being abandoned, often buried. Buildings could be built, used, used for something else, abandoned, buried, then excavated. It is especially the case that abandonment dates often are unrecorded because the people who might have recorded them are the people who have now left. Representing full timelines of long duration objects requires a way to handle condition changes with very high temporal uncertainty.

Nothing ever goes away

Summary

Temporal uncertainty is fundamental to historical data and a true "native" historical tool must handle it by design. This uncertainty can be somewhat managed by building a data set of factoids that adhere closely to what specific research is known. Ideally, the data set doesn't include many range factoids that then need to be removed as additional research is available. We created the exists factoid specifically to address this. This better represents the temporal uncertainty inherent in the data, provides a clearer and more verifiable citation, and still allows an event factoid later if more research identifies a more precise date.