Versions Compared

Old Version 3

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 4

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • mets element
    • @PROFILE fixed value="http://www.dspace.org/schema/aip/1.0/mets.xsd" (this is how we identify an AIP manifest)
    • @OBJID URN-format persistent identifier (Handle) if available, or else a unique identifier.
    • @LABEL title if available
    • @TYPE DSpace object type, one of "DSpace ITEM", "DSpace COLLECTION", "DSpace COMMUNITY".
    • @ID is a globally unique identifier, such as {{dspace67075091976862014717971209717749394363{{.
      • Wiki Markup
        <span style="color: red">@IDs should be used wherever available, I'll put a note about forming IDs in the profile spec.</span>
\[OK, but how unique does the ID have to be, just within the document or amongst all other AIP documentes? --lcs\]
<span style="color: red">I can't imagine a scenario where we would reference an ID within a METS document from without that document, except for perhaps the <code>mets@ID</code>.  I would say the <code>mets@ID</code> should be unique amongst all AIP documents, but the other IDs should just be unique within the document.</span>
  • mets/metsHdr element
    • @CREATEDATE timestamp that AIP was created.
    • @LASTMODDATE last-modified date on Item, or nothing for other objects.
      • mets defines these attributes as describing the METS document itself, we use them to describe the AIP, which sometimes we think of as the METS document, but more often think of as the 'package' – i.e. the METS document and all the files. I don't have a problem with the use Larry put forth, but we need to mention it in a prolife. I wonder if these dates shouldn't rather be in a techMD section, or maybe both.
    • agent element:
      • @ROLE = "CUSTODIAN",
      • @TYPE = "OTHER",
      • @OTHERTYPE = "DSpace Archive",
      • name = Site handle.
  • mets/dmdSec element
    • object's descriptive metadata crosswalked to MODS (or whatever the METS default is)
      • See link to RW's Comments Page below for notes on use of MODS
    • object's descriptive metadata in DSpace native DIM intermediate format, to serve as a complete and precise record for restoration or ingestion into another DSpace.
      • We should require mets/dmdSec@OTHERMDTYPE if @MDTYPE = "OTHER"
    • When the mdWrap @TYPE value is OTHER{{, the element MUST include a value for the {{@OTHERTYPE attribute which names the crosswalk that produced (or interprets) that metadata, e.g. {{AIP-TECHMD{{.
  • mets/amdSec element - admin (technical, source, rights, and provenance) metadata for the entire archival object.
    • rightsMD elements of the following TYPEs:
      • DSpaceDepositLicense if the object has a deposit license, it is contained here.
      • CreativeCommonsRDF If the object is an Item with a Creative Commons license expressed in RDF, it is included here.
      • CreativeCommonsText If the object is an Item with a Creative Commons license in plain text, it is included here.
    • sourceMD elements - recorded twice, once in DSpace native format, once in PREMIS:
      NOTE: PREMIS is only implemented for Bitstreams at the moment, and for the forseeable future.
      • DSpace native format: MDTYPE="OTHER" OTHERMDTYPE="{{AIP-TECHMD{{" (see Crosswalks section below for details'')
      • PREMIS expression of this technical metadata for archival object. (To be done later.)
    • digiprovMD
      • When History data is available, includes a section of TYPE="DSpaceHistory" containing an RDF/XML rendition of the history data for the object. For internal AIPs, the history is stored in an external bitstream in the asset store; for self-contained packages it is a file in the package.
  • mets/amdSec elements - technical metadata for each of an Items's Bitstreams, both in PREMIS and DIM formats
  • mets/fileSec element
    • For archival objects of type ITEM:
    • mets/fileSec/fileGrp/file element
      • Set @SIZE to length of the bitstream. There is a redundant value in the techMD but it is more accessible here.
      • Set @MIMETYPE, @CHECKSUM, @CHECKSUMTYPE to corresponding bitstream values. There is redundant info in the techMD.
      • SET @SEQ to bitstream's SequenceID if it has one.
    • For archival objects of types COLLECTION and COMMUNITY:
      • Only if the object has a logo bitstream, there is a fileSec with one fileGrp child of {{@TYPE="LOGO"{{.
      • The fileGrp contains one file element, representing the logo Bitstream. It has the same file format, checksum, etc fields as the Item content bitstreams, but does not include metadata section references or a SequenceID.
      • See the main structMap for the reference to this file.
  • mets/structMap - Primary structure map, @LABEL="DSpace Object", @TYPE="LOGICAL"
    • For COLLECTION objects: Top-level div has one child:
      1. div with @TYPE="MEMBERS"{{. For every Item in the Collection, it contains a {{div with an mptr linking to the Handle of that Item. Its @LOCTYPE="HANDLE"{{, and {{@xlink:href value is the raw Handle.
      • If Collection has a Logo bitstream, there is an fptr reference to it in the very first {{div{{.
    • For COMMUNITY objects: Top-level div has two children:
      1. div with @TYPE="SUBCOMMUNITIES"{{. For every Sub-Community in the Community it contains a {{div with an mptr linking to the Handle of that Community. Its @LOCTYPE="HANDLE"{{, and {{@xlink:href value is the raw Handle.
      2. div with @TYPE="COLLECTIONS"{{. For every child Collection, it contains a {{div with an mptr linking to the Handle of that Collection. Its @LOCTYPE="HANDLE"{{, and {{@xlink:href value is the raw Handle.
      • If Community has a Logo bitstream, there is an fptr reference to it in the very first {{div{{ div.
    • ITEM objects have the same kind of simple structure map as SIP/DIP: top level div with a div under it for each visible Bitstream.
      • If Item has primary bitstream, put it in first {{structMap/div/fptr{{.
  • mets/structMap - Structure Map to indicate object's Parent
    • Contains one div element which has the unique attribute value TYPE="AIP Parent Link" to identify it as the older of the parent pointer.
      • It contains a mptr element whose xlink:href attribute value is the raw Handle of the parent object, e.g. {{1721.1/4321{{.<p>In order to restore a DSpace archive from internal AIPs in the asset store, the parent of each object must be available at the surface level of the METS document so the object can be instantiated under its correct parent before the metadata (which may also name the parent) is crosswalked.

Wiki Markup
\[Rob Wolfe's Comments on METS Usage|AipPrototype-RWComments\]

Crosswalks

DIM Descriptive Elements for Collection objects

...

Start with a DSpace archive that has the AIP Prototype patched into
its code base. Prepare internal AIPs for the first time with the command:

Panelcode

  dsrun org.dspace.administer.AIPManager -u -a -v -e _admin-user_

Be sure that command completed successfully; check standard output
and the DSpace log for errors.

...

You should periodically run the command

Panelcode

 dsrun org.dspace.administer.AIPManager -u -a -e _admin-user_

to update internal AIPs for objects that have been changed or added.
Once a day should be enough.

...

To create an AIP in a file, use this command template:

Panelcode

 /dspace/bin/dsrun org.dspace.app.packager.Packager -d -t AIP -e _eperson_ -i _handle_ _file-path_

for example:

Panelcode

 /dspace/bin/dsrun org.dspace.app.packager.Packager -d -t AIP -e florey@mit.edu -i 1721.1/4567 aip4567.zip

The command needs to run under the identify of an EPerson with permission to read the specified object.

To create an internal AIP, just add the package parameter internal=true to the command.
The resulting "package" will be a METS manifest document, e.g.

Panelcode

 /dspace/bin/dsrun org.dspace.app.packager.Packager -d -t AIP -e florey@mit.edu -i 1721.1/4567 -o internal=true mets.xml

Ingesting External AIPs

To ingest an AIP and create a new object under a parent of your choice, add the ignoreParent and ignoreHandle package parameters to the command:

Panelcode

 /dspace/bin/dsrun org.dspace.app.packager.Packager -s -t AIP -e _eperson_ -p _parent-handle_ -o ignoreParent=true -o ignoreHandle=true _file-path_

If you leave out these package-parameter
options, the AIP package ingester will
attempt to install the AIP under the parent handle it had before,
and give it back its original Handle. After all, the point of
AIPs was to reproduce the exact object that was exported. When you are effectively using the AIP as a SIP, however, you may not want it back under the same parent or handle, so there is a way to override these features.

...

Here is an example of ingesting an AIP with the "-r" option:

Panelcode

 /dspace/bin/dsrun org.dspace.app.packager.Packager -s -t AIP -e _eperson_ -p 123456789/0  -r  _file-path_

If you are restoring an entire archive, or a hierarchy of objects,
from external AIPs, then you'll have to ingest the "ancestors" first:
for example, ingest the top-level Communities, then the sub-Communities and Collections under them, and so on, and finally
the Items when all the Collections are ready. You'll have to
examine each package to determine its parent handle, and the
handle of the object it creates, to determine the order.

...

  • aipManager.dispatcher
    name of the Event Dispatcher for the AIPManager application; when restoring an archive from AIPs, it is best to set this to a dispatcher that calls the search and browse consumers, but not History.
  • aip.packager
    plugin name of the Packager used to ingest and disseminate AIPs; by default it is {{AIP{{.
  • mets.dspaceAIP.ingest.crosswalk.''mdSecType''
    crosswalk plugin (either XML or Stream-oriented) to be called to interpret the given mdSec type. To ignore a section, set it to NULLSTREAM (for stream data) or NIL for XML.
  • aip.disseminate.''mdSecName''
    Sets the type name and crosswalks associated with each metadata section under the METS {{amdSec: sourceMD, techMD, rightsMD, digiprovMD{{. Value is comma-separated list of mdSecType:pluginName specifiers. For example:
    aip.disseminate.techMD = PREMIS
  • aip.disseminate.dmd
    Sets the crosswalks and type names of descriptive metadata sections to include; value format is the same as the admin MD sections.
  • aip.ingest.createEperson
    When value is "true", AIP ingester will create an EPerson if needed so it can set the Submitter of a newly-created Item to the "correct" value. An EPerson created this way cannot login. Default is false.

...