Description

Assumptions

Key Concepts

Dependencies

Background Documentation

Description

Unknown macro: {multi-excerpt} Describes an entity for a location, with structure among Locations (rooms in buildings). Relations provide, e.g., formal description of where a CollectionObject is, over time.

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:

Where does a CollectionObject go on acquisition?
Where is it when researcher asks?
Report on the location of CollectionObjects in a collection (e.g., what is in a given room).
Report on the location history of an object (provenance).
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

/wiki/spaces/COL/pages/666272978
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.

Browser not supported