Page History

...

You'll want to have some content (Communities, Collections & Items) to test with!

Exporting AIPs

Export Modes & Options

All AIP Exports are done by using the Dissemination Mode (-d option) of the packager command.

There are two main "modes" types of AIP Dissemination you can run the AIP packager inperform:

• 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 (including child objectsof 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)

...

Ingesting / Restoring AIPs

Again, like export, there are two main "modes" you can run the AIP packager in:

• Single AIP (default) - Ingests just an AIP describing a single DSpace object. So, if you ran it in this default mode for a Collection AIP, you'd just create a DSpace Collection from the AIP (but not ingest any of its child objects)
• Hierarchy (including child objects) - Ingests the requested AIP describing an object, plus the AIP for all child objects. Some examples follow:
  • For a Site - this would create all Communities, Collections & Items based on the located AIP files
  • For a Community - this would create that Community and all SubCommunities, Collections and Items based on the located AIP files
  • For a Collection - this would create that Collection and all contained Items based on the located AIP files
  • For an Item – this just create the Item (including all Bitstreams & Bundles) based on the AIP file.

...

Ingestion Modes & Options

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).
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.

Again, like export, there are two types of AIP Ingestion you can perform (using any of the above modes):

• Single AIP (default) - Ingests just an AIP describing a single DSpace object. So, if you ran it in this default mode for a Collection AIP, you'd just create a DSpace Collection from the AIP (but not ingest any of its child objects)
• Hierarchy of AIPs (by including the --all or -a option after the mode) - Ingests the requested AIP describing an object, plus the AIP for all child objects. Some examples follow:
  • For a Site - this would ingest all Communities, Collections & Items based on the located AIP files
  • For a Community - this would ingest that Community and all SubCommunities, Collections and Items based on the located AIP files
  • For a Collection - this would ingest that Collection and all contained Items based on the located AIP files
  • For an Item – this just ingest the Item (including all Bitstreams & Bundles) based on the AIP file.

The difference between "Submit" and "Restore/Replace" modes

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

• Submission Mode (-s) - creates a new object
  • 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

• Restore / Replace Mode - restores a new object (as if from a backup)
  • By default, the Handle specified in the AIP is restored
    • However, 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)
  • By default, the object is restored under the Parent specified in the AIP
    • However, 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 an Item to a Collection
  • Never adds a new Deposit License to Items (rather it restores the previous deposit license, as long as it is in the AIP)
  • Never adds new DSpace System metadata to Items (rather it just restores the metadata as specified in the AIP)

Submitting a Single AIP

...

If you leave out the -p parameter, the AIP package ingester will attempt to install the AIP under the same parent it had before. As you are also specifying the -s (submit) parameter, the packager will assume you want a new Handle to be assigned (as you are effectively specifying that you are submitting a new object). If you want the object to retain the Handle specified in the AIP, you can specify the -o ignoreHandle=false option to force the packager to not ignore the Handle specified in the AIP.

...

Submitting an AIP Hierarchy

...