Movement Service Description and Assumptions

Description

The Movement Service manages information around the movement of a CollectionObject - an instance of location change. This includes location changes resulting from movements between storage locations, such as between rooms or shelves. Movement will have an associated reason, which will often be another event entity, such as an exhibition, a loan, or a conservation action.

Assumptions

  • Movement must be associated with a Location, and this will be the new location. Not clear if it should also reference the old location. (ATS: Yes a movement will reference the old location.)
  • Movement may have date info, or it may be implicit in the temporal extent of the new Location. (ATS: I would argue that movement will always have date information.  A valid movement will contain a new location, a date, and the name of the person who moved the artifact.)
  • Movement will have a text description or notes. (ATS: I would argue that this is a 'may' rather than a 'will'.)
  • Movement may have associated insurance information.
  • Movement may have associated transport information.
  • Movement may have an associated condition report (or two: before and after?). (ATS: Most likely there will be one condition report per move i.e., update to location with new location (I moved artifact to this location and it was in this condition), 2nd update to location (I moved artifact from this location to this other location [could be back to former location] and it was in this condition.)
  • Movement may have designated responsible Persons in specific roles
    • Who is/was responsible for movement.
    • Who authorized the movement.

(ATS: Movement 'will' have ...  Movement tracking is basically, an audit function that is visible to the end user and is a vital part of the lifecycle of the artifact.  History of movement data is used to determine if an artifact will travel/be displayed, how frequently, in what conditions, etc.)

  • Movement can have a reason that is an event entity (Exhibition, Loan, etc.)
  • Movement has a process that can be represented as states (is this something we should model here, or in some associated workflow?):(ATS: I would say we model it in the event workflow.)
    • Request/Proposal
    • In research (establishing objects, noting condition, current locations, projected future locations)
    • In preparation for Transport
    • In Transit
    • Verifying condition at destination
    • etc.

Key Concepts

  • Need to distinguish what goes into Movement as fixed information, versus the possible association of other entities to a Movement instance as annotations or reasons.

ATS: As mentioned above, the key elements in movement are old location (carried over from immediate previous movement record and is displayed for verification purposes as in, yes, I found this artifact in the last noted location), the new location, the person who moved it, date of movement, purpose of movement (yes, this is the same thing as reason for movement), note/comment.  Spectrum units of information for Movement Information = Movement Contact, Method, Note, Reference Number, Planned Removal Date, Removal Date).  The idea of scheduling a move is a good one, but typically, comes into play only for large-scale movements (i.e., moving all artifacts to a new storage location).

Dependencies

Uses CollectionObject and Location, and may be the subject of business rules/workflow logic. Can be associated to other entities like Loan, Exhibit, ConditionReport, TransportInfo, Insurance, etc.

Background Documentation

Key Team Members

  • (Name(s) of members) is/are the primary tech team member(s) for this service
  • Need to identify the community members acting as Domain Experts.