Skip to content

Instantly share code, notes, and snippets.

@anarchivist
Created November 9, 2010 23:44
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save anarchivist/670061 to your computer and use it in GitHub Desktop.
Save anarchivist/670061 to your computer and use it in GitHub Desktop.
object modeling / definition for HyPATIA / Hydra
I think we are trying to define Fedora-based representations for two different
but related types of resources:
- Resources that represent archival entities, "components," or levels of
arrangement (e.g. collection, series, subseries, etc.). I will call these
ArchEntities for short.
- Resources that represent digital assets that manifest themselves as
*archival records* that form parts of ArchEntities. I will call these
RecordAssets.
ArchEntities should assist us in defining the structure, provenance, and
context of RecordAssets. ArchEntities represent aggregations, either of
other ArchEntities, or RecordAssets. In my opinion, the ArchEntities will be
more difficult to model, as their relationships are arguably more complex.
I am perfectly happy with relatively simple RecordAssets, which can be
further refined into related types of things if necessary. This in part
addresses the complexity of some of the file formats we need to deal with.
Additionally, we should *not* assume OR imply that one RecordAsset is
equivalent to one "archival record" or item. We cannot simply consider a
single item to be equivalent to a "file."
A larger question is whether or not RecordAssets need further refinement, in
the form of objects that represent the following:
- The original format of the asset, as received
- Representations of the asset in format(s) suitable for preservation
- Representations of the asset in format(s) suitable for access
I hope we can create a solid definition for our intellectual entities
that represent these archival entities. This is equally important to both
arrangement and description AND discovery and access.
Perhaps one direction we can consider is defining the layers related to
ArchEntities in a relatively strict way, and allow for more flexibility in
the layers related to the RecordAssets.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment