Page History

...

Makeup and Definition of AIPs

AIPs are Archival Information Packages

...

• AIP is a package describing one archival objectobject in DSpace.
  • The archival object may be a single Item, Collection, Community, or Site (Site AIPs contain site-wide information). Bitstreams are included in an Item's AIP.
  • Each AIP is logically self-contained, can be restored without rest of the archive. (So you could restore a single Item, Collection or Community)
  • Collection or Community AIPs do not include all child objects (e.g. Items in those Collections or Communities), as each AIP only describes one object. However, these container AIPs do contain references (links) to all child objects. These references can be used by DSpace to automatically restore all referenced AIPs when restoring a Collection or Community.
  • AIPs are only generated for objects which are currently in the "in archive" state in DSpace. This means that in-progress, uncompleted submissions are not described in AIPs and cannot be restored after a disaster. Permanently removed objects will also no longer be exported as AIPs after their removal. However, withdrawn objects will continue to be exported as AIPs, since they are still considered under the "in archive" status.
  • AIPs with identical contents will always have identical checksums. This provides a basic means of validating whether the contents within an AIP have changed. For example, if a Collection's AIP has the same checksum at two different points in time, it means that Collection has not changed during that time period.
  • AIP profile favors completeness and accuracy rather than presenting the semantics of an object in a standard format. It conforms to the quirks of DSpace's internal object model rather than attempting to produce a universally understandable representation of the object. When possible, an AIP tries to use common standards to express objects.
  • An AIP can serve as a DIP (Dissemination Information Package) or SIP (Submission Information Package), especially when transferring custody of objects to another DSpace implementation.
  • In contrast to SIP or DIP, the AIP should include all available DSpace structural and administrative metadata, and basic provenance information. AIPs also describe some basic system level information (e.g. Groups and People).

...

For more specific details of AIP format / structure, along with examples, please see DSpace AIP Format.

Running the Code

Exporting AIPs

...

To export in single AIP mode (default), use this '"packager' " command template:

 [dspace]/bin/dspace packager -d -t AIP -e <eperson> -i <handle> <file-path>

...

• Submission Mode (-s mode) - creates a new object (AIP is treated like a SIP)
  • By default, a new Handle is always assigned
    • However, you can force it to use the handle specified in the AIP by specifying -o ignoreHandle=false as one of your parameters
  • By default, a new Parent object must be specified (using the -p parameter). This is the location where the new object will be created.
    • However, you can force it to use the parent object specified in the AIP by specifying -o ignoreParent=false as one of your parameters
  • By default, will respect a Collection's Workflow process when you submit an Item to a Collection
    • However, you can specifically skip any workflow approval processes by specifying -w parameter.
  • Always adds a new Deposit License to Items
  • Always adds new DSpace System metadata to Items (includes new 'new "dc.date.accessioned'", '"dc.date.available'", '"dc.date.issued' " and '"dc.description.provenance' " entries)
  • WARNING: Submission mode may not be able to maintain Item Mappings between Collections.  Because these mappings are recorded via the Collection Handles, mappings may be restored improperly if the Collection handle has changed when moving content from one DSpace instance to another.

...