Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Description

The basic description of the exhibition service goes here.

Description requires work

Exhibition (may share "superclass" with Collection) - has a host of annotations along with some core info. Associated to objects. Exhibit has temporal quality (when it was on display). Will have Location association (with temporality) for a traveling exhibit. Object association may have temporal quality, or Exhibition association may be to a qualified Exhibition/Location/time-period instance. Some objects may only be in an exhibit for a while, because of damage/theft/other concerns.

Note that the CollectionObject entity is inherently hierarchical, and so Exhibition may just be a CollectionObject that is formally marked, and that may have some additional information. Need to clarify which aspects of the Exhibition entity are not covered by CollectionObject capabilities - we want to minimize duplication. Unlike a Collection, an Exhibition has a temporal aspect of when it was active (although the information remains). An Exhibition has some notion of state as well (actually, this is a better way to think of the temporal aspect), associated to the workflow of planning, travelling, on display (at some location), etc. In addition, an Exhibition is inherently more dynamic w.r.t. membership over time, since CollectionObjects may only be part of an exhibit for portions of its travels (due to conservation, insurance, or other constraints). We should be able to model most of this with some combination of workflow state, Movement (for travelling exhibits, and possibly for the local movement associated with display), Location (including local references as well as remote references for travelling exhibits), and Loan (to model travelling exhibits).

Boilerplate structure and text below

Much of the structure and text below this point is boilerplate copied in from the relevant New Service template.

Assumptions

  • Try to be explicit and exhaustive, but not pedantic.
    • ~pschmitz@berkeley.edu: If there is an active discussion or comment, you may want to call it out as a sub-bullet. This example also uses a color macro to call it out, and provides a link to a given user to indicate that this is a particular contributor's position.

Subtopic

  • More assumptions around peripheral subject
    • Ex. An example of the case
  • Yet another assumption
    • Details of the assumption
      • Nitty-gritty detail 1
      • Nitty-gritty detail 2

Key Concepts

  • Especially things that become common sense, and so usually missed by new reviewers

Dependencies

  • Note other services that are consumed or that are closely related to this one

Background Documentation

  • If we have notes from community design meetings, link to them here.
  • If we have relevant sections in Spectrum or another such document, link to them here (or cite section numbers, etc.)
  • No labels