Page History

...

There are two types of AIP Dissemination you can perform:

• Single AIP (default, using -d option) - Exports just an AIP describing a single DSpace object. So, if you ran it in this default mode for a Collection, you'd just end up with a single Collection AIP (which would not include AIPs for all its child Items)
• Hierarchy of AIPs (using the -d --all or -d -a option) - Exports the requested AIP describing an object, plus the AIP for all child objects. Some examples follow:
  • For a Site - this would export all Communities, Collections & Items within the site into AIP files (in a provided directory)
  • For a Community - this would export that Community and all SubCommunities, Collections and Items into AIP files (in a provided directory)
  • For a Collection - this would export that Collection and all contained Items into AIP files (in a provided directory)
  • For an Item – this just exports the Item into an AIP as normal (as it already contains its Bitstreams/Bundles by default)

...

Ingestion of AIPs is a bit more complex than Dissemination, as there are several different "modes" available:

1. Submit/Ingest Mode (-s option, default) – submit AIP(s) to DSpace in order to create a new object(s) (i.e. AIP is treated like a SIP – Submission Information Package)
2. Restore Mode (-r option) – restore pre-existing object(s) in DSpace based on AIP(s). This also attempts to restore all handles and relationships (parent/child objects). This is a specialized type of "submit", where the object is created with a known Handle and known relationships.
3. Replace Mode (-r -f option) – replace existing object(s) in DSpace based on AIP(s). This also attempts to restore all handles and relationships (parent/child objects). This is a specialized type of "restore" where the contents of existing object(s) is replaced by the contents in the AIP(s). By default, if a normal "restore" finds the object already exists, it will back out (i.e. rollback all changes) and report which object already exists.

...

It's worth understanding the primary differences between a Submission (specified by -s parameter) and a Restore (specified by -r parameter).

• 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 specifiying -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 'dc.date.accessioned', 'dc.date.available', 'dc.date.issued' and 'dc.description.provenance' entries)

• Restore / Replace Mode (-r mode) - restores a previously existing object (as if from a backup)
  • By default, the Handle specified in the AIP is restored
    • However, for restores, you can force a new handle to be generated by specifying -o ignoreHandle=true as one of your parameters. (NOTE: Doesn't work for replace mode as the new object always retains the handle of the replaced object)
    • Although a Restore/Replace does restore Handles, it will not necessarily restore the same internal IDs in your Database.
  • By default, the object is restored under the Parent specified in the AIP
    • However, for restores, you can force it to restore under a different parent object by using the -p parameter. (NOTE: Doesn't work for replace mode, as the new object always retains the parent of the replaced object)
  • Always skips any Collection workflow approval processes when restoring/replacing an Item in a Collection
  • Never adds a new Deposit License to Items (rather it restores the previous deposit license, as long as it is stored in the AIP)
  • Never adds new DSpace System metadata to Items (rather it just restores the metadata as specified in the AIP)

...