...
Current AIPs have too much interdependency. Parent objects (e.g. Collections) enumerate all of their children (e.g. Items). This means that every time a new child object (e.g. Item) is added/removed, it also must be added/removed from all of its parents' AIPs.
...
Decision (on 15 April 2010): We (Richard R, Bill H, Tim D) decided that child objects should enumerate their parents (so you can find an Item's parent Collection from that Item's AIP), but parents should not enumerate all their children. Although this may make restoring content more complex (in order to restore a Collection, you need to look at each Item to determine if it is a child of that Collection), it will lessen inter-dependencies between AIPs.
| Wiki Markup |
|---|
------
\[16 April 2010 - Tim\] I realized we may need to rethink this decision. If there is no way to determine children of parents easily, than you may encounter the following scenario with restoring a single Collection along with all its Items: |
- Suppose all your AIPs currently take up 1TB of space. Likely, nearly 90% of that space (900GB) is for Item AIPs, as they tend to be larger and more frequent than Community or Collection AIPs.
- Suppose you also want to restore a single Collection.
- Since you know the Collection you need to restore, obviously you can immediately restore the Collection metadata from the Collection AIP
- However, if the Collection AIP does not enumerate its Items, you will be stuck having to parse 900GB of Item AIPs to determine which belong to this Collection. This becomes even more inefficient if you are using a service like DuraCloud, as it will force you to download 900GB of Item AIPs in order to unzip them and determine which belong to this Collection.
This scenario makes me think we either need Collection AIPs to continue to list all Item members, or we need another way to relatively easily "lookup" which Items belong to that Collection.
What content goes in an AIP?
...