...
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 less-than-ideal scenario when restoring a single Collection along with all its Items: |
...
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.
-------
| Wiki Markup |
|---|
*\[01 June 2010 - Mark\]* It's not necessary to parse entire Item AIPs since they are ZIP archives; just read the manifests. If they are stored remotely (e.g. DuraCloud) then you need to be able to run the parser there and send back the lists of interesting items. |
On the other hand, we could extract the relationships into an index for each Collection and package that separately. Relationships are not part of the things related – the difficulty lies in trying to shove the relationship inside any one of the related entities.
-------
What content goes in an AIP?
...
Tim feels that ResourcePolicies (DSpace access rights) might need to be stored eventually in some way. Otherwise, when restoring an Item, you'll always have to default to making it publicly available (or default to Collection access rights).
Mark feels that restoring an object without its rights is too surprising to contemplate, but that this is separate from the question of whether and how to export roles.
Do we store Embargos in AIPs, so that we can restore them as needed?
...