Location Service Description and Assumptions

Description

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.

Assumptions

• 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.).

Key Concepts

• 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).

Dependencies

• 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.

Background Documentation

• 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

Key team members

• Patrick Schmitz is the primary tech team member for this service
• Need to identify the community members acting as Domain Experts.