Pleiades Conceptual Model

Entities

geographic names, geographic locations and regions, time periods, and places are the key entities in our model.

Representations

• Geographic names are represented in our system by Unicode strings, plus ASCII transliterations and attribute data
• Geographic locations/regions are represented by spatially-referenced geometries
• Time periods are represented by named date ranges
• A place is an association (grouping) of geographic names and geographic locations
  • In this model we will not distinguish between place points or larger regions (i.e., we call a space a place)

Details

In an unproblematic modern context, any geographic feature can be named and can be located precisely. In historical contexts, we may be unable to determine location, or we may be able to do so only imperfectly. On the other hand, we may be able to locate accurately a feature of interest, but we may be unable to discover its historical name(s), or we may be able to associate an attested name with a located feature only tentatively. Temporally, names come in and out of use. For some features, their locations and geospatial extents (the footprint or area of a province or lake, for example) can also change over time. Our ability to track these changes accurately varies. For examples of some geographic features as represented in the Barrington Atlas, see: BAtlasEntityExamples.

In terms of our computational context -- the Pleiades system itself -- the geographic features are represented by places. They constitute a major organizing mechanism for our data, as well as a primary point of interface and interaction for our human users and for various automated applications. Some of our applications and user interfaces will treat places as cartographic features. Others will treat them as collections of names or other attributes.

Our goal in the ongoing design and refinement of the place and its constituent entities is the ability to support all types of data represented cartographically and textually in the Barrington Atlas and its Map-by-Map Directories, while accomodating new functions unique to the computation context of Pleiades.

Some key aspects of our design deserve highlighting:

A place may have zero or more names

The Barrington Atlas makes this distinction. The maps, of course, are filled with physical features, only some of which are labeled. Culturally significant sites are usually labeled with their attested names or, failing knowledge of these, with the modern name. Some sites, known primarily through an individual archaeological survey, are labeled with their survey inventory number. In areas where interesting features with no known modern nor ancient name are common -- for example, small villas in Roman North Africa -- no label is used at all for the "nameless" sites.

A place may have zero or more locations

The Barrington Atlas provides only a single location for most features of interest. In a few cases, however, multiple locations are provided, as follows:

• Some very large settlements, such as Rome, are indicated as points on smaller scale overview maps, but the same settlements are given polygonal "urban sprawl" areas on larger scale maps
• A few entities (primarily coastlines) are given different geometries at different time periods, e.g., the Mediterranean coastline at the Maeander river delta

Names and locations are associated (certainly or uncertainly) with one or more time periods

The Barrington Atlas makes this distinction. Such associations indicate the places's period of activity, pertinence, attestation or currency.

Technical Implementation Details

The place and its components are implemented in Plone via the Pleiades Entity Product.

Diagram

The following diagram uses the conventions of the Unified Modeling Language (UML) to illustrate the key points made in prose, above. Implementation details, are best reviewed via the detailed Geographic Entity UML model.

For some of the associations and data fields, thesauri of legal values (also known as "controlled vocabularies") are employed to assist users in data entry and to ensure uniformity of data. For more information on this topic, see: Vocabularies.

Design Questions

Notes

We have preferred to use the title "place" over the common GIS term "feature" because the latter implies, for many people, a single record in a GIS dataset having one and only one geometry. An individual Pleiades place, by contrast, can have more than one geometry. This arrangement gives us the flexibility to address temporal change and other factors flexibly. Because of the historical, and therefore often fragmentary, nature of our dataset, we need to place the conceptual idea of space/place above toponomy and location.

Initial thoughts on a simple interoperability profile