Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Table of Contents
outlinetrue
stylenone

Relationships Between Bitstreams

...

Add the following API calls to the Bitstream object:

Code Block
    /** Constants describing the type of relationship: */
 '' ''
    // This Bitstream was derived from the contents of the related one.
    public static final int REL_TYPE_DERIVED     = 1;
 '' ''
    // This Bitstream is an alternate version of the related one.
    public static final int REL_TYPE_ALTERNATE   = 2;
 '' ''
    // This Bitstream contains descriptive metadata about the related one.
    public static final int REL_TYPE_MD_DESC     = 3;
 '' ''
    // This Bitstream contains administrative metadata about the related one.
    public static final int REL_TYPE_MD_ADM      = 4;
 '' ''
    // This Bitstream contains technical metadata about the related one.
    public static final int REL_TYPE_MD_TECH     = 5;

 '' ''
      // This Bitstream contains provenance metadata about the related one.
    public static final int REL_TYPE_MD_PROV     = 6;
 '' ''
    // This Bitstream contains rights metadata about the related one.
    public static final int REL_TYPE_MD_RIGHTS   = 7;
 '' ''
    /**
     * Establish a relationship with the target Bitstream.  The nature
     * of that relationship is described by setRelationshipType().
     * When relevant, the object executing this method is the "slave"
     * (e.g. the derived one) in the relationship.
     * @param related Bitstream object which is target (master) of relationship.
     */
    public void setRelatedBitstream(Bitstream related)
 '' ''
    /**
     * Get related Bitstream.
     * @return related (master) Bitstream, or null if none has been set.
     */
    public Bitstream getRelatedBitstream()
 '' ''
    /**
     * Set the type of relationship this Bitstream has with the
     * one set in setRelatedBitstream().  See the REL_TYPE_*
     * constants for details.
     * @param rel indicates type of relationship.
     */
    public void setRelationshipType(int rel)
 '' ''
    /**
     * @returns type of relationship, or 0 if none has been set.
     */
    public int getRelationshipType()
 '' ''
    /**
     * Get all the Bitstreams with relationships to this one.
     * @return Array related Bitstreams, or empty Array if there are none.
     */
    public Bitstream[] getBitstreamsRelatedToSelf()
 '' ''
    /**
     * Get all the Bitstreams with relationships to this one, and
     * a Bundle name matching the indicated one.
     * @param bundleName bundle name to match.
     * @return Array related Bitstreams, or empty Array if there are none.
     */
    public Bitstream[] getBitstreamsRelatedToSelf(String bundleName)

For example, if you have a "content" Bitstream and want to find out if
it has a thumbnail image, you would call

...

getBitstreamsRelatedToSelf("THUMBNAIL")

...

, and check if the array
returned has any elements.

Looking for LOM metadata is a more involved application: First you'd
have to get any related Bitstreams in the

...

METADATA

...

bundle, and then
search through those for one of the appropriate type (perhaps indicated by
its

...

BitstreamFormat

...

).

Establishing a relationship is easy. In code that creates a Bitstream
by deriving it from another Bitstream, like a media filter plugin,
it's obvious: set the new Bitstream to be related from the one from
which it was derived, and

...

setRelationshipType(REL_TYPE_DERIVED).

When ingesting a package (SIP) that includes an encoding of relationships
between Bitstreams (e.g. METS), the ingester code should also
make the appropriate calls to

...

setRelatedBitstream()

and

...

setRelationshipType()

...

to mark metadata, derived, and alternate Bitstreams.

The implementation is straightforward. It can be done by adding two
columns to the Bitstream table; one containing a

...

bitstream_id

...

key
(or

...

NULL

...

) to the related Bitstream, and another with an integer for
the relationship type.

...

I think we need set relationships analogous to the METS fileGrp or div elements. Right now DSpace has the concept of bundles, but those bundles are used to separate derived bitstreams from original/content bitstreams. This means the user has no way of selecting what bundle to place a bitstream in, nor can they create bundles. Everything the user adds to an item is placed in the

...

original/content

...

bundle.

If container relationships are added at the bitstream level there are several possible uses. The first use that comes to mind is relating scanned pages together into chapters, sections, or other groupings. Another possibility is relating together different types of pictures for one physical artifact. There are various use cases, and most depend on the type of artifact being stored.

...

  • Follow Jim's suggestion about Code Block N-N relationships
  • Make these relationships interact with bundles; this would allow administrative and technical metadata to be applied to a bundle of bitstreams.
  • Make bundles recursive, so that bundles can contain other bundles.
  • Enable the user to create and modify bundles.

...