Description
The basic description of the exhibition service goes here.
Text below requires editing, splitting between some/all of description, assumptions, concepts, and dependencies
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 page structure and text below this point is boilerplate, copied in from the relevant New Service template. Further work is needed to complete this page.
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
- Details of the assumption
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.)
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.