2010 Leadership Grant

Deploying Collections

Skip to end of metadata
Go to start of metadata

From Jan Eklund, describing how the current HAVRC system handles "works" (of art) and components (which are parts of the work record.  In seurat, there are separate work and component tables.

It looks as if there are only 2 fields in the HAVRC component table
that do not correspond to fields in the works table.  They are
component_id and component_loc.

The combination of work_id and component_id constitutes the unique
identifier that links works and work components to image records.
These component works could be described as works in the CSPace
environment and related as children to the parent work in a hierarchy.
But without an explicit relationship type (like "component of"),
HAVRC would have no way to distinguish between true components and
other kinds of work-to-work relationships that are recorded in the
related works table.  Things like "preparatory sketch for", "design
for", "formerly larger context for", etc.  Some of these extrinsic
relationships are not strictly speaking hierarchical and it could be

The component_loc is the field in HAVRC is used to describe the
position or location of the component within the larger work.  This is
a free text optional use field, and can contain page numbers or folio
numbers for sequencing, positional description (e.g. left wing), or
any other descriptive phrase that positions the component work within
the larger context of the parent work.  I looked at CDWA, and they
record this kind of stuff in different places.  They recommend fields
for components quantity (HAVRC does not have this- they only have a
count of the components entered, not a total count of components) and
component type (HAVRC component_object_type).  CDWA also has a
separate category for orientation and arrangement for complex works
that looks particularly useful for architecture and installation art.
There is a discussion of different approaches to describing component
works at


  • No labels