...
There are already relationships between Bitstreams (in DSpace 1.3 and
1.4) but they are not recorded in any formal or obvious way.
For example, some of the
...
MediaFilter
...
classes add a derivative Bitstream
for each of the "content" Bitstreams, such as a thumbnail image.
To associate
the thumbnail image with its full-size counterpart, the thumbnail Bitstream
is given the same name as its master image with an extra image file
extension tacked onto the end.
So when the Web UI has the opportunity to display a thumbnail image of
a Bitstream, it must know to look for a Bitstream with an extra
...
".jpg"
...
appended to its name.
This ad hoc solution is not scalable and it violates modularity.
The media filter plugin and the Web UI have to share a secret: the formula
for naming thumbnail Bitstreams. For another application, e.g. a METS package
disseminator, to associate thumbnail images with the original versions,
it has to be let in on the secret.
It isn't scalable because every other media filter plugin with its own
kind of derivative Bitstream has to invent its own bitstream-naming
convention.
There is also the limitation that Bitstream names are actually metadata,
and they need not be unique. It is perfectly legal for an Item to have
two image Bitstreams named
...
"illustration.gif"
...
, but the thumbnail naming convention breaks down.
However, my objection is not so much to the method (magic Bitstream
names), as to the lack of a formal API to enforce the rules and make the
Bitstream-association mechanism available to all other modules.
...