Created
November 9, 2010 23:44
-
-
Save anarchivist/670061 to your computer and use it in GitHub Desktop.
object modeling / definition for HyPATIA / Hydra
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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