Location Service Description and Assumptions

We will want to ask what objects are (or were) in a location, and/or to associate insurance with a location. This latter implies that we need more than just a string.

Also need to describe:

• The hierarchic nature of Locations

• The CollectionObjectLocation relation and its semantics

• Distinguish Location from simple Contact information that has an address, etc. See also Questions.

Consider that there are several uses:

1. Where does a CollectionObject go on acquisition?

2. Where is it when researcher asks?

3. Report on the location of CollectionObjects in a collection (e.g., what is in a given room).

4. Report on the location history of an object (provenance).

5. Where did an object come from, where was it found?

Several require either structured reference or vocab-suggestion to ensure consistency.

Several require a containment model to make roll-up reporting and search useful.

Note that Location association for an object must be time-based (has begin and end times).

Location association (i.e., the binding of a CollectionObject to a Location) should also support some descriptive info, like reason. The reason may also be something like a Loan or Exhibition. This implies that there is a reason and a reason-type.

• Locations have fixed relationships to one another (they are about physical containment or relation).

• Locations have type:

  • Some are geographic in nature

  • Some are geopolitical in nature

  • Some are built structures

  • Some are containers

• Locations have extent. This may be modeled explicitly (if approximately), as in the case of a geographic or geopolitical extent, or implicitly (with only a general size indication) as in the case of a container like a box.

• The definition and properties of a location, including the name, extent, containment hieracrchy, etc., may be temporally bound. E.g., "East Germany" as a concept no longer exists. We must be able to model historical as well as current locations, extents, etc.

• Locations are associated to other entities, and these associations have semantics. We may model these as types, including some of the following:

  • Storage Location

  • Origin of an object

  • Historical location of an object (as when an object was traded before entering a collection).

• Location associations can have a temporal nature:

  1. The temporal extents are mutually exclusive - an object cannot be in two places at once.

  2. The temporal extents may not cover a range - there may be gaps in history

• Location associations may have a movement associated to them, annotating the event that prompted the change of location (an exhibit, a loan, a conservation action, etc.).

• Location Term

• Geolocation (lat/long) and relation to Location

• Extent models

• Containment (site within city within county within state, etc.) vs. storage structure (boxes sitting on shelves in a storage unit in a room in a building).

• We may need to describe some general temporal logic and import it here. There are other things with exclusive temporal relations.

• KSS relationship: KSS has deferred the specification of a Location service. They currently describe a location attribute for things like Resources (requires KSS auth), but this is just a string. If we define a flexible Location model, they would likely be able to use it.

• Location and Movement Control - Functional Requirements

• Need links to notes from community design meetings.

• Need links to relevant sections in Spectrum.

• Consider reviewing Specify Data Model

• Patrick Schmitz is the primary tech team member for this service

• Need to identify the community members acting as Domain Experts.