The Orbis Initiative: A Pelagios for Networks? [Take 2]

NOTE: This a “refresh” of the earlier post of the same title, edited to reflect some new terminology (indicated by red) and replace the conceptual model figure.

data-triptych

A small sampling of historical network datasets

I believe there would be widespread interest in a global collaboratively developed system, organized similarly to Pelagios, aimed at creating and linking data records for attested historical journeys (e.g. itineraries, and flows of people, commodities, information, correspondence) and ways (roads, rivers, canals, sea currents). In this provisional semantics, a journey is evidence of some person(s) or thing(s) moving from here to there (then there, etc.), at a known, approximate or estimated time and/or in a particular sequence, as attested in some source. A way is the physical medium for journeys.

Both journeys and ways can be represented as two or more places and one or more segments (nodes and edges in network parlance). Place nodes are necessarily “geographically embedded” and typically represented by feature centroids. The geometry of ways between nodes for various types of journeys may be known, estimated, or in the case of some flow data, of no concern.

Historical gazetteers in the Pelagios ecosystem represent only named places. Most are point-like features (e.g. settlements, sites); increasingly, polygonal features are included as well (e.g. regions, administrative areas). But what of historical movement—journeys between named places along ways? The simple data models used for the Pelagios interchange format and for most gazetteers do not accommodate journeys and ways.

Not surprisingly, the first early geographic document geo-parsed in Pelagios’ Recogito tool describes an itinerary: “Itinerarium Burdigalense: the Itinerarium Burdigalense (or Bordeaux Itinerary) […] a travel document that records a Pilgrim route between the cities of Bordeaux and Jerusalem.” Although we know each attested place was part of a traveled route, by virtue of its association with a text having “itinerarium” in its title, those relationships are not recorded formally in gazetteers, and therefore not readily discoverable and analyzable as routes and components of networks.

The Orbis Initiative

In February, 2015 I submitted a proposal to the National Science Foundation for a fairly large grant ($1.6m over 3 years) to develop the Orbis Initiative. Although reviews were quite positive, it was not funded. The project was designed to facilitate the creation, archiving, discovery, linking, and analysis of historical geospatial network data for “everywhere and every when” [1-page summary]. The project name was borrowed from an interactive scholarly web application I helped build, originally published by Stanford University Libraries in 2012 and significantly upgraded in 2014, ORBIS: The Stanford Geospatial Network Model of the Roman Empire (hereafter, ORBIS: Rome).

Whereas ORBIS: Rome is a model of travel and transport for a particular region and period aimed at answering the research questions of one Classical scholar, Walter Scheidel–and built by Scheidel and Elijah Meeks–the Orbis Initiative would instead be a system for creating, storing, and linking geospatial network data spanning potentially all places and periods—a distributed repository along with a set of relatively simple interactive web-based tools to facilitate its use. The design and proposed development of the Orbis Initiative is a response to researchers who have expressed a desire to build ORBIS: Rome-like applications for their own areas and periods of study. Importantly, the intent is not to expand the ORBIS: Rome network transport model, but to provide a generic data infrastructure and tools to facilitate development of other models and modeling approaches.

I remain convinced this would be a worthwhile undertaking and subsequently, two opportunities have emerged to begin some of the work described in the grant proposal, at a much smaller initial scale; I’ll discuss one of them here.

A Community of Interest?

Writing the Orbis Initiative grant entailed recruiting collaborators with varied exemplar datasets being developed for ongoing research. Several of those projects are concerned with processes of cultural diffusion and commercial activity—separately and in concert—in East and Central Asia and between Asia and Europe over extended periods. Their aggregated temporal extent is 7th century BCE to 16th century AD. Researchers in those groups, and now a few others, have indicated an immediate pragmatic interest in exposing and linking their data for common benefit. Meetings to discuss next steps have begun.

Something Like Pelagios

An Orbis Initiative would replicate several aspects of the Pelagios Project, which has gained terrific momentum in developing online resources, methods and software for linking historical gazetteers. I believe Pelagios’ success is due in large part to its “ground-up” nature—the fact it answers some immediate requirements of a distinct community of interest for the Classical Mediterranean. Its spatial and temporal extents and software tool development scope are growing organically, expanding upon smallish proofs-of-concept that people find useful. Tools developed so far facilitate data creation (Recogito) and data discovery (Peripleo). The Pelagios approach offers a stark contrast with some “build it and they will come” data repository projects attempted in recent years.

In the same vein, a pragmatic start to an Orbis Initiative could be seeded by meeting the requirements of the above-mentioned community of interest to link (and in a sense gather) their historical geospatial network data: connections by road, river, canal, and sea route between the places attested in Pelagios-compatible gazetteers.

A Conceptual Model

So, networks of journeys and flows are different in kind from place locations as commonly understood, and as such require a different, somewhat more elaborate data model. Furthermore, while all spatial data may include temporal attributes, some network data—itineraries for example—are inherently temporal; in fact they are events. Flows are essentially aggregated movement events.

In my experience a helpful first step in data modeling is to create a conceptual model of the entities and relations of what is being represented—an ontology design pattern if you will. Typically a collaborative undertaking, the resulting visualization provides a basis for the data schemas to follow, be they relational or graph. I’ve taken a first second stab at such a model, borrowing a bit from a recently published trajectory pattern (Hu, et al 2013); input is invited and essential.

journey-way-concepts_construction

Data Format

The GeoJSON data format is in common use and provides a good starting point for a standardized representation of trajectories and paths. Granting that much data is initially gathered in spreadsheets, by and large if it is to be mapped or analyzed spatially, it makes its way into human-readable GeoJSON or the binary shapefile. GeoJSON represents geographic Features in a FeatureCollection, and spatial attributes are represented in a required Geometry object, but time is not accounted for natively. Although temporal attributes of a Feature can be recorded as one or more of a Feature’s Properties there is no norm or best practice for this and mapping software that consumes GeoJSON does not typically look for or make use of temporal attributes.

This can potentially be remedied by an extension to GeoJSON, such as the Topotime format I’ve been developing. Topotime data is valid GeoJSON, but it includes a new, optional When object, and leverages the sparingly used GeometryCollection object that is found in the GeoJSON specification.

One of my tasks at hand—which I welcome collaborative input on—is testing the efficacy of the Topotime model for the several types of historical geospatial network data found in the wild. I’ve begun posting some sample data to the Orbis Initiative GitHub repo.

The Basics of Topotime

Topotime was initially conceived as a means for representing historical temporal data that is vague and otherwise uncertain, for visualization in browser timeline software and for the analysis of probabilistic relationships between and amongst events and periods.

The goals of the Topotime project have recently both broadened and simplified considerably—it is now aimed at extending the GeoJSON format to account for time (including some of the difficult historical cases), without breaking GeoJSON. That is, Topotime data would be recognized as GeoJSON by any software that supports GeoJSON. The work-in-progress described on the Topotime repo is now a little behind samples I’m pushing to the Orbis Initiative repo (kgeographer/oi).

I am working through varied and more complex data examples. When a suitable data format is settled, I’ll write some basic software that accesses Topotime’s unique attributes to browse and search several exemplar datasets.

The following is a snippet to give a sense of it:

topotime-snippet

Next Steps

This effort does not have institutional support at this time, but if enough people feel it’s worth pursuing, we should seek it. UPDATE: A small group of colleagues and I will be submitting grant proposals soon.

As mentioned above, a small group representing several active research projects focused on Asian maritime and land routes will be meeting soon to assess whether Topotime or something like it is appropriate for a “Pelagios for Networks.” We will make our results public for discussion, through this blog and the Pelagios Linked Past SIG forum. More later…and comments are welcome.

Posted in Uncategorized | 2 Comments

The Orbis Initiative: a Pelagios for Networks?

data-triptych

A small sampling of historical network datasets

I believe there would be widespread interest in a global collaboratively developed system, organized similarly to Pelagios, aimed at creating and linking data records for attested historical trajectories (e.g. itineraries, routes, commercial flows, correspondence) and paths (roads, rivers, canals, sea currents). In this provisional semantics, a trajectory is evidence of some person(s) or thing(s) moving from here to there (then there, etc.), at a known, approximate or estimated time and/or in a particular sequence, as attested in some source. A path is the physical medium for trajectories.

Both paths and trajectories can be represented as two or more places and one or more segments (nodes and edges in network parlance). Place nodes are necessarily “geographically embedded” and typically represented by feature centroids. The geometry of paths between nodes for various types of trajectories may be known, estimated, or in the case of some flow data, of no concern.

Historical gazetteers in the Pelagios ecosystem represent only named places. Most are point-like features (e.g. settlements, sites); increasingly, polygonal features are included as well (e.g. regions, administrative areas). But what of historical movement—trajectories between named places along paths? The simple data models used for the Pelagios interchange format and for most gazetteers do not accommodate trajectories and paths.

Not surprisingly, the first early geographic document geo-parsed in Pelagios’ Recogito tool describes an itinerary: “Itinerarium Burdigalense: the Itinerarium Burdigalense (or Bordeaux Itinerary) […] a travel document that records a Pilgrim route between the cities of Bordeaux and Jerusalem.” Although we know each attested place was part of a traveled route, by virtue of its association with a text having “itinerarium” in its title, those relationships are not recorded formally in gazetteers, and therefore not readily discoverable and analyzable as routes and components of networks.

The Orbis Initiative

In February, 2015 I submitted a proposal to the National Science Foundation for a fairly large grant ($1.6m over 3 years) to develop the Orbis Initiative. Although reviews were quite positive, it was not funded. The project was designed to facilitate the creation, archiving, discovery, linking, and analysis of historical geospatial network data for “everywhere and every when.” The project name was borrowed from an interactive scholarly web application I helped build, originally published by Stanford University Libraries in 2012 and significantly upgraded in 2014, ORBIS: The Stanford Geospatial Network Model of the Roman Empire (hereafter, ORBIS: Rome).

Whereas ORBIS: Rome is an authored model of travel and transport for a particular region and period aimed at answering the research questions of one Classical scholar (Walter Scheidel), the Orbis Initiative is instead a system for creating, storing, and linking geospatial network data spanning potentially all places and periods—a distributed repository along with a set of relatively simple interactive web-based tools to facilitate its use. The design and proposed development of the Orbis Initiative is a response to researchers who have expressed a desire to build ORBIS: Rome-like applications for their own areas and periods of study. Importantly, the intent is not to expand the ORBIS: Rome network transport model, but to provide a generic data infrastructure and tools to facilitate development of other models and modeling approaches.

I remain convinced this would be a worthwhile undertaking and subsequently, two opportunities have emerged to begin some of the work described in the grant proposal, at a much smaller initial scale; I’ll discuss one of them here.

A Community of Interest?

Writing the Orbis Initiative grant entailed recruiting collaborators with varied exemplar datasets being developed for ongoing research. Several of those projects are concerned with processes of cultural diffusion and commercial activity—separately and in concert—in East and Central Asia and between Asia and Europe over extended periods. Their aggregated temporal extent is 7th century BCE to 16th century AD. Researchers in those groups, and now a few others, have indicated an immediate pragmatic interest in exposing and linking their data for common benefit. Meetings to discuss next steps have begun.

Something Like Pelagios

An Orbis Initiative would replicate several aspects of the Pelagios Project, which has gained terrific momentum in developing online resources, methods and software for linking historical gazetteers. I believe Pelagios’ success is due in large part to its “ground-up” nature—the fact it answers some immediate requirements of a distinct community of interest for the Classical Mediterranean. Its spatial and temporal extents and software tool development scope are growing organically, expanding upon smallish proofs-of-concept that people find useful. Tools developed so far facilitate data creation (Recogito) and data discovery (Peripleo). The Pelagios approach offers a stark contrast with some “build it and they will come” data repository projects attempted in recent years.

In the same vein, a pragmatic start to an Orbis Initiative could be seeded by meeting the requirements of the above-mentioned community of interest to link (and in a sense gather) their historical geospatial network data: connections by road, river, canal, and sea route between the places attested in Pelagios-compatible gazetteers.

A Conceptual Model

So, networks of trajectories are different in kind from place locations as commonly understood, and as such require a different, somewhat more elaborate data model. Furthermore, while all spatial data may include temporal attributes, some network data—itineraries for example—are inherently temporal; in fact they are events. Flows are essentially aggregated movement events.

In my experience a helpful first step in data modeling is to create a conceptual model of the entities and relations of what is being represented—an ontology design pattern if you will. Typically a collaborative undertaking, the resulting visualization provides a basis for the data schemas to follow, be they relational or graph. I’ve taken a first stab at such a model, using a recently published trajectory pattern (Hu, et al 2013) as a point of departure; input is invited and essential.

path-trajectory-concepts_v2

Data Format

The GeoJSON data format is in common use and provides a good starting point for a standardized representation of trajectories and paths. Granting that much data is initially gathered in spreadsheets, by and large if it is to be mapped or analyzed spatially, it makes its way into human-readable GeoJSON or the binary shapefile. GeoJSON represents geographic Features in a FeatureCollection, and spatial attributes are represented in a required Geometry object, but time is not accounted for natively. Although temporal attributes of a Feature can be recorded as one or more of a Feature’s Properties there is no norm or best practice for this and mapping software that consumes GeoJSON does not typically look for or make use of temporal attributes.

This can potentially be remedied by an extension to GeoJSON, such as the Topotime format I’ve been developing. Topotime data is valid GeoJSON, but it includes a new, optional When object, and leverages the sparingly used GeometryCollection object that is found in the GeoJSON specification.

One of my tasks at hand—which I welcome collaborative input on—is testing the efficacy of the Topotime model for the several types of historical geospatial network data found in the wild.

The Basics of Topotime

Topotime was initially conceived as a means for representing historical temporal data that is vague and otherwise uncertain, for visualization in browser timeline software and for the analysis of probabilistic relationships between and amongst events and periods.

The goals of the Topotime project have recently both broadened and simplified considerably—now essentially aimed at extending the GeoJSON format to account for time (including some of the difficult historical cases), without breaking GeoJSON. That is, Topotime data would be recognized as GeoJSON by any software that supports GeoJSON.

Work-in-progress is described, with a few toy examples, at https://github.com/kgeographer/topotime. I’m planning to work through varied and more complex data examples soon, then write some basic software that accesses Topotime’s unique attributes.

The following is a snippet to give a sense of it:

topotime_smal-example

Next Steps

This effort does not have institutional support at this time, but if enough people feel it’s worth pursuing, we should seek it.

As mentioned earlier, a small group representing several active research projects focused on Asian maritime and land routes will be meeting soon to assess whether Topotime or something like it is appropriate for a “Pelagios for Networks.” We will make our results public for discussion, possibly through the Pelagios SIG infrastructure. More later… and comments are welcome.

Posted in Uncategorized | Leave a comment

Under (re)construction

A re-design is in progress…a couple of years’ worth of posts were lost to time during a switch of hosters. Ah well.

Posted in Uncategorized | 3 Comments

Topotime and Place

two-up_blogI’ve recently been co-developing with colleague Elijah Meeks something called Topotime, which at this stage is experimental software for rendering timelines and doing some computational reasoning about historical timespans, such as calculating overlap. The first adjective we use to describe this work is pragmatic, because we felt we had thought hard enough about time versus temporality for digital humanities work [1], and built enough temporal data models and timelines, that we should begin some concrete steps to “operationalize” [2] our views and personal wishlists in some working software. The results to date have just been publicly released on GitHub, and we hope other will participate in its further development. Elements of the Topotime data model and software are novel (we think) but it is built around a couple of common and successful design patterns.

First, Topotime models Periods in PeriodCollections, much as GeoJSON models Features in FeatureCollections. GeoJSON Features have a typed geometry and unlimited number of user-defined properties. Topotime Periods have typed timespans (tSpan) and unlimited user-defined properties. Topotime can be written as a JSON object, just as GeoJSON is. I find the symmetry between representation requirements for spatial things and temporal things astonishing, although it would probably not surprise physicists. For starters, both have names, metrical representations (geometries, even), and are usefully typed. The close relationship between places and periods will be a refrain on this blog.

features_periods-compare

The second borrowed pattern is representing the uncertain boundaries of intervals as intervals themselves, not “instants” (there aren’t very many instants in historiography). The result is a quad of start (s), latest start (ls), earliest end (ee), and end (e). The first and third of these can be stated in natural language as “not before,” and the second and fourth as “not after.” This pattern appears in Simile Timeline and in several scholarly works I cited in an earlier blog post.

temporal-geometry_fig4

Topotime extends that pattern to allow any of these to be qualified as “about” or “approximately” (~) some day, month or year. It also parses an elaboration of the starting and ending spans (sls and eee respectively). The result is a function returning a probability y for any time x. The area under the function’s curve, although not a useful number in and of itself, can be used to good effect in computing overlap with other period or event timespans, and with query areas (as discussed in this short paper [PDF], and earlier demonstrated by Kauppinen et al [3]). The Topotime model also permits specifying intermittent, multi-part timespans which can be cyclical or irregular.

Meeting of minds (and conceptualizations)

Topotime’s name, courtesy of Elijah, stems from our wish to capture certain topological relations between periods (their timespans actually). We can know a period or event began after another and not know when that is exactly but wish to represent and reason about that adjacency. Similarly, we may know two events (lives, e.g.) overlapped, but have only minimal information about their starts and ends.

As it turned out, tackling that issue led to a more involved data model. Its hard to know where to put the bounds on development projects, due to the EAGER principle we live by here: Everything’s A Graph and Everything’s Related. Both Elijah and I have been working at event data models for multiple projects for several years, and this was an opportunity to operationalize some of our individual perspectives, which differ but seem to have important overlaps as well.

These are a couple of the agreements and how they’ve appeared in Topotime so far:

  • There are temporal things, which include events, historical periods, and lifespans of things, people and groups (e.g. nations). They all share some representation requirements, so in software we can make a super-class for them, potentially specializing distinctive differences in sub-classes later. But for the time being every temporal thing is a Period, for lack of a better all-encompassing term, and we don’t do anything different for events, lifespans and historical periods. If you add an attribute like class or css_class to the generic periods you can make them render distinctively in a timeline app.
  • Periods have meaningful relationships to other Periods, some of which are non-topological. For this, Topotime recognizes a relations[ ] array of simple subject-predicate-object triples. This will be written as JSON-LD soon, and therefore be Semantic Web compatible. That is, although relationships between the timespans of two events are metrical, measured, and possibly incidental (they overlap, abut, are disjoint, etc.), relationships between periods are a different thing. The most basic is compositional, or mereological ( Peter Simons’ Parts: A study in ontology is fascinating, and short). Events are composed of or contained by other events. We use a part_of relation for this.

Other relationships researchers might wish to encode include caused, required, led_to, etc., none of which we deal with yet. At minimum we might like to visualize our understandings and arguments about these in timeline interfaces (perhaps along the lines of Nowiskie and Drucker’s PlaySpace 2003 [1]). Quite possibly, we can find further interesting ways to compute over them, but they first must find their way into data models.

[1] Although not as hard as Bethany Nowiskie and Johanna Drucker! I only recently came across a trove of their interesting work theorizing time v. temporality, and building out pilots for novel timeline applications for digital humanities. For example, the Temporal Modelling Project and PlaySpace 2003 [screenshots]

[2] A term with plenty of history, but recently the subject of a really nice Stanford Lit Lab pamphlet by Franco Moretti.

[3] Tomi Kauppinen, Glauco Mantegari, Panu Paakkarinen, Heini Kuittinen, Eero Hyvönen, and Stefania Bandini. (2010). Determining Relevance of Imprecise Temporal Intervals for Cultural Heritage Information Retrieval. International Journal of Human-Computer Studies, Volume 68, Issue 9, pp. 549-560 , Elsevier. Preprint PDF

Posted in topotime | Leave a comment

Topotime: Qualitative reasoning for historical time

semi-intervals_1

Fig. 1 – Christian Freksa’s (1992) semi-intervals – Allen’s interval relations as components of temporal conceptual neighborhoods, discussed below

When my colleague Elijah Meeks recently tweeted about the possibility of a temporal topology data standard (“topotime” as he called it), my reaction was: Fantastic! Maybe the time has arrived, so to speak, for a proper Period datatype in relational databases like PostgreSQL, to meet the needs of historical scholarship—a comprehensive means for qualitative reasoning about historical time. And while we’re at it, how about a generic Period ontology design pattern that could be used in any RDFS/OWL representations?  It’s not that a start towards topotime hasn’t been made, only that we can advance things considerably if we as a community get specific about general requirements. Hmm…specifics about generality.

Our standard options in relational databases at the moment are to use one or more ISO 8601 date fields or integer fields to cobble together something that meets our immediate requirements: for example, either a single DATE or YEAR, or START and END fields in a form of either yyyy‑mm‑dd, or nnnn. We can then use the operators <, >, and = to readily compute the 13 relations of Allen’s interval algebra (before, meets, overlaps, starts, during, finishes-and their inverses-plus equals). In RDF-world, we find the Allen relations are present in CIDOC-CRM.

What more could we (humanist representers of time and temporality) possibly want? That question was the topic of a short talk I gave in a recent panel at the DH2013 in Lincoln, NE. How about a single Period field for starters—a compound date?

In fact, an existing extension for PostgreSQL written by Jeff Davis provides this (https://github.com/jeff-davis/PostgreSQL-Temporal), and I’ve used it several times. Davis provides, along with operators for standard Allen relations, several more to get finer grain, e.g. to differentiate between before (overlaps-or-left-of) and strictly-before. There are also numerous functions for computing relationships in SQL statements. A Period is entered as a date array that looks like this:

[ (yyyy-mm-dd), (yyyy-mm-dd) ]

The begin and end dates (and parts thereof) are still accessible using first(period) and last(period) functions, and these can be used in concert with PostgreSQL’s built-in date-part and interval functions to calculate periods of interest on the fly. For example, in a recent project we converted birth and death dates to Period lifetimes and calculated contemporaries as individuals who were adults ( >= 17 ) at the same time: overlaps( (first(lifetime)::date + 17 years, last(lifetime)), (1832-01-01, 1874-11-23)).

semi-intervals_2

Fig. 2 – The “survived-by” conceptual neighborhood merges several semi-interval relations

If you happen to be using PostgreSQL, this helps with many use cases, but we can and should go much further. I made a baby step in the course of dissertation research, by writing a series of Postgres functions to perform some minimal computation over Christian Freksa’s temporal conceptual neighborhoods (sets of 13 semi‑intervals) using the Period datatype (Fig. 2). These neighborhoods are sets of semi-interval relations corresponding to some common (and not so common) reasoning tasks. For example, survived-by merges less‑than, meets, overlaps(left), starts, and during. Freksa’s algebra has many more elements which I didn’t use, but should be considered going forward.

Now, what of uncertainty in its many forms—the vague, probabilistic, and contested data we routinely encounter? The many classes of uncertainty have been outlined in a fairly exhaustive taxonomy a decade ago by historical geographer Brandon Plewe (2002), and that work should be helpful in future modeling efforts. If an event began “most likely in late Spring, 1832 (Jones 2013),” when should its representation appear in a dynamic interactive visualization having a granularity of months? When it appears in a time-filtering application, how should it differ from an event that began in “April, 1832 (Smith 2012)?”

Application logic to do something about such cases would need an underlying temporal entity having a probability (0 – 1) and/or some kind of ‘confidence’ weight. If we’re talking about the span of the event, it’s a period bounded not by instants (dates) but by periods, each with an author and probability/confidence value.

In fact, some very nice research to formalize such temporal objects using periods bounded by periods has been done in the context of historical/heritage applications. Members of the FinnOnto group (Kaupinnen et al 2010) have developed a formal representation and algebra for fuzzy historical intervals (Fig. 3).

kaupinnen_1

Figure 3 – The period ‘‘from around the beginning of the 1st century B.C. to the first half of the 1st century A.D.’’ represented as a fuzzy temporal interval. The fuzzy bounds for start and end are 10- and 14-year periods respectively.

holmen_1

Fig. 4 – Deduction rule for A1 < A2, where A1, A2 are two points in time modeled as intervals.

In the realm of semantic (ontological) representations, Holmen and Ore (2009) have developed a database system based on the event-centric CIDOC-CRM that includes an algebra (Fig. 4) and temporal analyzer module to reduce fuzziness and aid in the creation of event sequences as “Stored Story Objects.” Like the previous work, period starts and ends are represented as intervals.

Ceri Binding (2009) developed a CIDOC-CRM based representation of multiple attestations of historical periods and their extents for the archaeological project, STARS.

All of the work I’ve mentioned seems to me compatible in fundamental respects. I believe that as a community of interest can we can collaboratively develop a few shared resources that would be very helpful for many research projects. For example, a Linked Data repository of historical periods along the lines of what Pleiades/Pelagios does for places in the Classical Mediterranean. Lex Berman of the Harvard Center for Geographical Analysis has given this a lot of thought and done some prototype work, as have others. What is the right venue for making this happen?

Another concrete goal is extending the Period datatype for PostgreSQL to allow a probability or confidence term for each bounding period. Once that is worked out, someone might even port it to ArcGIS. Yeah.

NOTE: These and related topics are among those to be addressed by a proposed new GeoHumanities SIG for the Alliance of Digital Humanities Organizations (ADHO) I’m co-instigating with Kathy Weimer of Texas A & M. Further word on that within a week or so.

Cited works

Binding, C. (2009). Implementing archaeological time periods using CIDOC CRM and SKOS. CAA 2009 Proceedings (http://hypermedia.research.southwales.ac.uk/media/files/documents/2010-06-09/ESWC2010_binding_paper.pdf)

Freksa, C. (1992). Temporal reasoning based on semi-intervals, Artificial Intelligence 54, 199-227
(http://cindy.informatik.uni-bremen.de/cosy/staff/freksa/publications/TemReBaSeIn92.pdf)

Kauppinen, T., Mantegari, G., Paakkarinen, P., Kuittinen,  H., Hyvonen, E., Bandini, S. (2010). Determining relevance of imprecise temporal intervals for cultural heritage information retrieval. International Journal of Human-Computer Studies 68 (2010) 549–560 (http://kauppinen.net/tomi/temporal-relevance-ijhcs2010.pdf)

Holmen, J., and Ore, C. (2009). Deducing event chronology in a cultural heritage documentation system. In CAA 2009 Proceedings (http://www.edd.uio.no/artiklar/arkeologi/holmen_ore_caa2009.pdf)

Plewe, B. (2002). The Nature of Uncertainty in Historical Geographic Information. Transactions in GIS, 6(4): 431-456. (http://dusk.geo.orst.edu/buffgis/TGIS_uncertainty.pdf)

Plewe, B. (2003). Representing Datum-level Uncertainty in Historical GIS. Cartography and Geographic Information Science, 30(4):319-334

 

Posted in topotime | Leave a comment