Guest User

Untitled

a guest
Jun 21st, 2018
300
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.79 KB | None | 0 0
  1. I think we are trying to define Fedora-based representations for two different
  2. but related types of resources:
  3.  
  4. - Resources that represent archival entities, "components," or levels of
  5. arrangement (e.g. collection, series, subseries, etc.). I will call these
  6. ArchEntities for short.
  7.  
  8. - Resources that represent digital assets that manifest themselves as
  9. *archival records* that form parts of ArchEntities. I will call these
  10. RecordAssets.
  11.  
  12. ArchEntities should assist us in defining the structure, provenance, and
  13. context of RecordAssets. ArchEntities represent aggregations, either of
  14. other ArchEntities, or RecordAssets. In my opinion, the ArchEntities will be
  15. more difficult to model, as their relationships are arguably more complex.
  16.  
  17. I am perfectly happy with relatively simple RecordAssets, which can be
  18. further refined into related types of things if necessary. This in part
  19. addresses the complexity of some of the file formats we need to deal with.
  20. Additionally, we should *not* assume OR imply that one RecordAsset is
  21. equivalent to one "archival record" or item. We cannot simply consider a
  22. single item to be equivalent to a "file."
  23.  
  24. A larger question is whether or not RecordAssets need further refinement, in
  25. the form of objects that represent the following:
  26.  
  27. - The original format of the asset, as received
  28. - Representations of the asset in format(s) suitable for preservation
  29. - Representations of the asset in format(s) suitable for access
  30.  
  31. I hope we can create a solid definition for our intellectual entities
  32. that represent these archival entities. This is equally important to both
  33. arrangement and description AND discovery and access.
  34.  
  35. Perhaps one direction we can consider is defining the layers related to
  36. ArchEntities in a relatively strict way, and allow for more flexibility in
  37. the layers related to the RecordAssets.
Add Comment
Please, Sign In to add comment