...
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.
-------
| Wiki Markup |
|---|
*\[01 June 2010 - Mark Diggory\]* I recommend considering this from the ORE aggregation style "standpoint". what we vaguely concluded a couple years ago is that a DSpace Collection is not an ORE Aggregation because it is open ended. ORE Aggregations are Finite, thus a DSpace Item as an ORE Aggregation will enumerate its children while a DSpace Collection will not. I support the idea of not listing all the child Items in a parent collection AIP or the collection aips within the parent Community AIP. The original behavior of the AIP prototype's ability to reconstitue a repository community/collection/item hierarchy based on the contents did require fully traversing the repository to discover the ancestry of any one Community, Collection, Item, Bundle or Bitstream AIP. Being able to traverse the manifests without actually having gzip archives of content in bitstream will give us the capability to do this efficiently. Perhaps there should be a means within the asset-store to separate the AIP manifests from the rest of the bitstreams so that they may be traversed quickly. |
This very much makes me think of both the Fedora Store and the Semantic Store project and how we will address the subject of Entities for DSpace Communities, Collections, Items and Bitstreams. IMO, DSpace 2.0 Entities and AIPs are highly correlated, Where an AIP is an Archival Representation of all or part of an Entity. Likewise, Services in the DSpace Service framework may be seen as different views/subsets of data/state of the content you refer to as an AIP.
-------
What content goes in an AIP?
...