...
This page proposes a change to the DSpace object model to
express relationships between the Bitstreams belonging to an item.
It also adds calls to the "business logic" API to set and discover
these relationships.
...
The first two kinds of relationships are not symmetric: the "derived"
_and _"is metadata about" relationships have clear master/slave roles. The
alternate relationship can be considered symmetric. Note: If one of the
"alternate" formats was created by a preservation operation, that fact
should be recorded in provenance metadata, it does not need to be in the
object model as master/slave roles.
...
I had the same thought as Scott, that this proposal begins to put us on the slippery slope of dealing with arbitrary complex digital objects (e.g. scanned documents or multimedia publications or different views of a built artifact). DSpace has always studiously avoided handling these directly because there are an infinite number of such relationships and making sense of them in the submission, curation, or end-user interface is a huge job... take, for example, the Fedora solution of a "relationship ontology" (see http://www.fedora.info/download/2.1.1/userdocs/digitalobjects/introRelsExt.html
) and the complexities that leads to in the applications that must make sense of them. Sometimes it's justified, but it comes at a very high price. The DSpace philosophy so far has been to put that complexity into the object encoding schemas like METS, MPEG21, XFDU, IMS-CP, and the like, and let the application and UI layers deal with those, rather than relying on DSpace's native bundle/bitstream data model.
...