Page History

{toc}

h2. General AIP Structure / Examples

Generally speaking, an AIP is an Zip file containing a METS manifest and all related content bitstreams, license files and any other associated files.

Some examples include:
* Site AIP  (Sample: [^SITE-example.zip])
** METS contains basic metadata about DSpace Site and persistent IDs referencing all Top Level Communities
** METS also contains a list of all Groups and EPeople information defined in the DSpace system.
* Community AIP (Sample: [COMMUNITY@123456789-1.zip|^COMMUNITY-123456789-1.zip])
** METS contains all metadata for Community and persistent IDs referencing all members (SubCommunities or Collections).  Package may also include a Logo file, if one exists.
** METS contains any Group information for Commmunity-specific groups (e.g. {{COMMUNITY\_<ID>\_ADMIN}} group).
** METS contains all Community permissions/policies (translated into [METSRights schema|http://www.loc.gov/standards/rights/METSRights.xsd])
* Collection AIP (Sample: [COLLECTION@123456789-2.zip|^COLLECTION-123456789-2.zip])
** METS contains all metadata for Collection and persistent IDs referencing all members (Items).  Package may also include a Logo file, if one exists.
** METS contains any Group information for Collection-specific groups (e.g. {{COLLECTION\_<ID>\_ADMIN}}, {{COLLECTION\_<ID>\_SUBMIT}}, etc.).
** METS contains all Collection permissions/policies (translated into [METSRights schema|http://www.loc.gov/standards/rights/METSRights.xsd])
* Item AIP (Sample: [ITEM@123456789-8.zip|^ITEM-123456789-8.zip])
** METS contains all metadata for Item and references to all Bundles and Bitstreams.  Package also includes all Bitstream files.
** METS contains all Item/Bundle/Bitstream permissions/policies (translated into [METSRights schema|http://www.loc.gov/standards/rights/METSRights.xsd])

_Notes:_
* Bitstreams and Bundles are second-class archival objects; they are recorded in the context of an Item.
* BitstreamFormats are not even second-class; they are described implicitly within Item technical metadata, and reconstructed from that during restoration
* EPeople are only defined in Site AIP, but may be referenced from Community or Collection AIPs
* Groups may be defined in Site AIP, Community AIP or Collection AIP.  Where they are defined depends on whether the Group relates specifically to a single Community or Collection, or is just a general site-wide group.

*What is NOT in AIPs*
* DSpace Site configurations (\[dspace\]/config/ directory) or customizations are not described in AIPs
* DSpace Database model (or customizations therein) is not described in AIPs



h2. AIP Details: METS Structure

{note}This METS Structure is based on the structure decided for the original [AipPrototype], developed as part of the PLEDGE project.{note}


* {{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 (i.e. Handle) if available, or else a unique identifier. (e.g. "hdl:123456789/1")
** {{@LABEL}} title if available
** {{@TYPE}} DSpace object type, one of "DSpace ITEM", "DSpace COLLECTION", "DSpace COMMUNITY" or  "DSpace SITE".
** {{@ID}} is a globally unique identifier, built using the Handle and the Object type (e.g. {{dspace-COLLECTION-hdl:123456789/3}}).
* {{mets/metsHdr}} element
** {{@LASTMODDATE}} last-modified date for a DSpace Item, or nothing for other objects.
** {{agen>agent}} element:
*** {{@ROLE}} = "CUSTODIAN",
*** {{@TYPE}} = "OTHER",
*** {{@OTHERTYPE}} = "DSpace Archive",
*** {{name}} = _Site handle_.  (Note: The Site Handle is of the format {{\[handle_prefix\]/0}}, e.g. "123456789/0")
** {{agent}} element:
*** {{@ROLE}} = "CREATOR",
*** {{@TYPE}} = "OTHER",
*** {{@OTHERTYPE}} = "DSpace Software",
*** {{name}} = "DSpace \[version\]" (Where "\[version\]" is the specific version of DSpace software which created this AIP, e.g. "1.7.0")
*  {{mets/dmdSec}} element(s)
** By default, two {{dmdSec}} elements are included for all AIPs:
**# object's descriptive metadata crosswalked to MODS (specified by {{mets/dmdSec/mdWrap@MDTYPE="MODS"}}). See [#MODS Schema] section below for more information.
**# 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. Specified by {{mets/dmdSec/mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DIM"}}.  See [#DIM (DSpace Intermediate Metadata) Schema] section below for more information.
** 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. {{DIM}}.
*  {{mets/amdSec}} element(s)
** One or more {amdSec} elements are include for all AIPs.  The first {amdSec} element contains administrative metadata (technical, source, rights, and provenance) for the entire archival object. Additional {amdSec} elements may exist to describe parts of the archival object (e.g. Bitstreams or Bundles in an Item).
*** {{techMD}} elements.  By default, two types of {{techMD}} elements may be included:
**** {{PREMIS}} metadata about an object may be included here (_currently only specified for Bitstreams (files)_).  Specified by {{mdWrap@MDTYPE="PREMIS"}}. See [#PREMIS Schema] section below for more information.
**** {{DSPACE-ROLES}} metadata may appear here to describe the Groups or EPeople related to this object (_currently only specified for Site, Community and Collection).  Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DSPACE-ROLES"}}.  See [#DSPACE-ROLES Schema] section below for more information.
*** {{rightsMD}} elements.  By default, there are four possible types of {{rightsMD}} elements which may be included:
**** {{METSRights}} metadata may appear here to describe the permissions on this object.  Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="METSRIGHTS"}}.  See [#METSRights Schema] section below for more information.
**** {{DSpaceDepositLicense}} if the object is an Item and it has a deposit license, it is contained here. Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DSpaceDepositLicense"}}.
**** {{CreativeCommonsRDF}} If the object is an Item with a Creative Commons license expressed in RDF, it is included here. Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="CreativeCommonsRDF"}}.
**** {{CreativeCommonsText}} If the object is an Item with a Creative Commons license in plain text, it is included here. Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="CreativeCommonsText"}}.
*** {{sourceMD}} element.  By default, there is only one type of {{sourceMD}} element which may appear:
**** {{AIP-TECHMD}} metadata may appear here. This stores basic technical/source metadata about in object in a DSpace native format. Specified by {{mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="AIP-TECHMD"}}. See [#AIP Technical Metadata Schema (AIP-TECHMD)] section below for more information.
*** {{digiprovMD}} element.
**** _Not used at this time._
* {{mets/fileSec}} element
** For archival objects of type ITEM:
*** Each distinct Bundle in an Item goes into a {{fileGrp}}.   The {{fileGrp}} has a {{@USE}} attribute which corresponds to the Bundle name.
*** Bitstreams in bundles become {{file}} elements under {{fileGrp}}.
*** {{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.  (For DSpace, the {{@CHECKSUMTYPE="MD5"}})
**** 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 {{@USE="LOGO"}}. 
*** The {{fileGrp}} contains one {{file}} element, representing the logo Bitstream.  It has the same {{@MIMETYPE}}, {{@CHECKSUM}}, {{@CHECKSUMTYPE}} attributes as the Item content bitstreams, but does NOT include metadata section references or a {{@SEQ}} attribute.
*** See the main {{structMap}} for the {{fptr}} reference to this logo file.
* {{mets/structMap}} - Primary structure map, {{@LABEL="DSpace Object", @TYPE="LOGICAL"}}
** For ITEM objects: 
**#  Top-Level {{div}} with {{@TYPE="DSpace Object Contents"}}.
**#* For every Bitstream in Item it  contains a {{div}} with {{@TYPE="DSpace BITSTREAM"}}.  Each Bitstream {{div}} has a single {{fptr}} element which references the bitstream location.
*** If Item has primary bitstream, put it in {{structMap/div/fptr}} (i.e. directly under the {{div}} with {{@TYPE="DSpace Object Contents"}})
** For COLLECTION objects: 
**#  Top-Level {{div}} with {{@TYPE="DSpace Object Contents"}}. 
**#* For every Item in the Collection, it contains a {{div}} with {{@TYPE="DSpace ITEM"}}. Each Item {{div}} has up to two child {{mptr}} elements:
**#*# One linking to the Handle of that Item. Its {{@LOCTYPE="HANDLE"}}, and {{@xlink:href}} value is the raw Handle.
**#*# (Optional) one linking to the location of the local AIP for that Item (if known).  Its {{@LOCTYPE="URL"}}, and {{@xlink:href}} value is a relative link to the AIP file on the local filesystem.
*** If Collection has a Logo bitstream, there is an {{fptr}} reference to it in the very first  {{div}}.
** For COMMUNITY objects: 
**#  Top-Level {{div}} with {{@TYPE="DSpace Object Contents"}}. 
**#* For every Sub-Community in the Community it  contains a {{div}} with {{@TYPE="DSpace COMMUNITY"}}.  Each Community {{div}} has up to two {{mptr}} elements:
**#*# One linking to the Handle of that Community. Its {{@LOCTYPE="HANDLE"}}, and {{@xlink:href}} value is the raw Handle.
**#*# (Optional) one linking to the location of the local AIP file for that Community (if known).  Its {{@LOCTYPE="URL"}}, and {{@xlink:href}} value is a relative link to the AIP file on the local filesystem.
**#* For every Collection in the Community there is a {{div}} with {{@TYPE="DSpace COLLECTION"}}.  Each Collection {{div}} has up to two {{mptr}} elements:
**#*# One linking to the Handle of that Collection. Its {{@LOCTYPE="HANDLE"}}, and {{@xlink:href}} value is the raw Handle.
**#*# (Optional) one linking to the location of the local AIP file for that Collection (if known).  Its {{@LOCTYPE="URL"}}, and {{@xlink:href}} value is a relative link to the AIP file on the local filesystem.
*** If Community has a Logo bitstream, there is an {{fptr}} reference to it in the very first  {{div}}.
** For SITE objects: 
**#  Top-Level {{div}} with {{@TYPE="DSpace Object Contents"}}. 
**#* For every Top-level Community in Site, it contains a {{div}} with {{@TYPE="DSpace COMMUNITY"}}. Each Item {{div}} has up to two child {{mptr}} elements:
**#*# One linking to the Handle of that Community. Its {{@LOCTYPE="HANDLE"}}, and {{@xlink:href}} value is the raw Handle.
**#*# (Optional) one linking to the location of the local AIP for that Community (if known).  Its {{@LOCTYPE="URL"}}, and {{@xlink:href}} value is a relative link to the AIP file on the local filesystem.
* {{mets/structMap}} - Structure Map to indicate object's Parent, {{@LABEL="Parent", @TYPE="LOGICAL"}}
** 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}}.

h2. Metadata in METS

The following tables describe how various metadata schemas are populated (via DSpace Crosswalks) in the METS file for an AIP.

h3. DIM (DSpace Intermediate Metadata) Schema

[DIM Schema|DSpaceIntermediateMetadata] is essentially a way of representing DSpace internal metadata structure in XML.  DSpace's internal metadata is very similar to a Qualified Dublin Core in its structure, and is primarily meant for descriptive metadata.  However, DSpace's metadata allows for custom elements, qualifiers or schemas to be created (so it is extendable to any number of schemas, elements, qualifiers).  These custom fields/schemas may or may not be able to be translated into normal Qualified Dublin Core.  So, the DIM Schema must be able to express metadata schemas, elements or qualifiers which may or may not exist within Qualified Dublin Core.

In the METS structure, DIM metadata always appears within a {{dmdSec}} inside an {{<mdWrap MDTYPE="OTHER" OTHERMDTYPE="DIM">}} element. For example:
{code}
  <dmdSec ID="dmdSec_2190"> 
     <mdWrap MDTYPE="OTHER" OTHERMDTYPE="DIM">
      ...
     </mdWrap>
  </dmdSec>
{code}

By default, DIM metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.dmd = MODS, DIM
{code}


h4. DIM Descriptive Elements for Item objects

As all DSpace Items already have user-assigned DIM (essentially Qualified Dublin Core) metadata fields, those fields are just exported into the [DIM Schema|DSpaceIntermediateMetadata] within the METS file.

h4. DIM Descriptive Elements for Collection objects

For Collections, the following fields are translated to the DIM schema:

|| DIM Metadata Field || Database field or value ||
| dc.description | 'introductory_text' field |
| dc.description.abstract | 'short_description' field |
| dc.description.tableofcontents | 'side_bar_text' field |
| dc.identifier.uri | Collection's handle |
| dc.provenance | 'provenance_description' field |
| dc.rights | 'copyright_text' field |
| dc.rights.license | 'license' field |
| dc.title | 'name' field |


h4. DIM Descriptive Elements for Community objects

For Communities, the following fields are translated to the DIM schema:

|| DIM Metadata Field || Database field or value ||
| dc.description | 'introductory_text' field |
| dc.description.abstract | 'short_description' field |
| dc.description.tableofcontents | 'side_bar_text' field |
| dc.identifier.uri | Handle of Community |
| dc.rights | 'copyright_text' field |
| dc.title | 'name' field |


h4. DIM Descriptive Elements for Site objects

For the Site Object, the following fields are translated to the DIM schema:

|| Metadata Field || Value ||
| dc.identifier.uri | Handle of Site (format: {{\[handle_prefix\]/0}}) |
| dc.title | Name of Site (from dspace.cfg 'dspace.name' config) |

h3. MODS Schema

By default, all DSpace descriptive metadata (DIM) is also translated into the [MODS Schema|http://www.loc.gov/standards/mods/] by utilizing DSpace's {{MODSDisseminationCrosswalk}}.  DSpace's DIM to MODS crosswalk is defined within your {{\[dspace\]/config/crosswalks/mods.properties}} configuration file.  This file allows you to customize the MODS that is included within your AIPs.

For more information on the MODS Schema, see http://www.loc.gov/standards/mods/mods-schemas.html

In the METS structure, MODS metadata always appears within a {{dmdSec}} inside an {{<mdWrap MDTYPE="MODS">}} element. For example:
{code}
  <dmdSec ID="dmdSec_2189"> 
     <mdWrap MDTYPE="MODS">
      ...
     </mdWrap>
  </dmdSec>
{code}

By default, MODS metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.dmd = MODS, DIM
{code}

The MODS metadata is included within your AIP to support interoperability.  It provides a way for other systems to interact with or ingest the AIP without needing to understand the DIM Schema. You may choose to disable MODS if you wish, however this may decrease the likelihood that you'd be able to easily ingest your AIPs into a non-DSpace system (unless that non-DSpace system is able to understand the DIM schema). When restoring/ingesting AIPs, DSpace will always first attempt to restore DIM descriptive metadata.  Only if no DIM metadata is found, will the MODS metadata be used during a restore.

h3. AIP Technical Metadata Schema (AIP-TECHMD) 

The AIP Technical Metadata Schema is a way to translate technical metadata about a DSpace object into the [DIM Schema|DSpaceIntermediateMetadata].  It is kept separate from DIM as it is considered technical metadata rather than descriptive metadata.

In the METS structure, AIP-TECHMD metadata always appears within a {{sourceMD}} inside an {{<mdWrap MDTYPE="OTHER" OTHERMDTYPE="AIP-TECHMD">}} element.  For example:
{code}
  <amdSec ID="amd_2191"> 
      ...
      <sourceMD ID="sourceMD_2198">
         <mdWrap MDTYPE="OTHER" OTHERMDTYPE="AIP-TECHMD">
         ...
         </mdWrap>
      </sourceMD>
      ...
  </amdSec>
{code}

By default, AIP-TECHMD metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.sourceMD = AIP-TECHMD
{code}

h4. AIP Technical Metadata for Item

|| Metadata Field || Value ||
| dc.contributor | Submitter's email address |
| dc.identifier.uri | Handle of Item |
| dc.relation.isPartOf | Owning Collection's Handle (_as a URN_) |
| dc.relation.isReferencedBy | All other Collection's this item is linked to (_Handle URN of each non-owner_) |
| dc.rights.accessRights | _"WITHDRAWN"_ if item is withdrawn |


h4. AIP Technical Metadata for Bitstream

|| Metadata Field || Value ||
| dc.title | Bitstream's name/title |
| dc.title.alternative | Bitstream's source (getSource()) |
| dc.description | Bitstream's description (getDescription()) |
| dc.format | Bitstream Format Description (getUserFormatDescription()) |
| dc.format.medium | Short Name of Format (getFormat().getShortDescription()) |
| dc.format.mimetype | MIMEType of Format (getFormat().getMIMEType()) |
| dc.format.supportlevel | System Support Level for Format (getFormat().getSupportLevel()) |
| dc.format.internal | Whether Format is internal (getFormat().isInternal()) |


*{color:red}Why are we recording the file format support status?  That's a DSpace property, rather than an Item property.  Do DSpace instances rely on objects to tell them their support status?{color}
** Format support and other properties of the BitstreamFormat are recorded here in case the Item is restored in an empty DSpace that doesn't have that format yet, and the relevant bits of the format entry have to be reconstructed from the AIP. --lcs

h4. AIP Technical Metadata for Collection

|| Metadata Field || Value ||
| dc.identifier.uri | Handle of Collection |
| dc.relation.isPartOf | Owning Community's Handle (_as a URN_) |
| dc.relation.isReferencedBy | All other Communities this Collection is linked to (_Handle URN of each non-owner_) |


h4. AIP Technical Metadata for Community

|| Metadata Field || Value ||
| dc.identifier.uri | Handle of Community |
| dc.relation.isPartOf | Handle of Parent Community (_as a URN_) |


h4. AIP Technical Metadata for Site

|| Metadata Field || Value ||
| dc.identifier.uri | Site Handle (format: {{\[handle_prefix\]/0}}) |


h3. PREMIS Schema

At this point in time, the [PREMIS Schema|http://www.loc.gov/standards/premis/] is only used to represent technical metadata about DSpace Bitstreams (i.e. Files).  The PREMIS metadata is generated by DSpace's {{PREMISCrosswalk}}.  Only the [PREMIS Object Entity Schema|http://www.loc.gov/standards/premis/schemas.html] is used.

In the METS structure, PREMIS metadata always appears within a {{techMD}} inside an {{<mdWrap MDTYPE="PREMIS">}} element.  PREMIS metadata is *always* wrapped withn a {{<premis:premis>}} element. For example:
{code}
  <amdSec ID="amd_2209"> 
      ...
      <techMD ID="techMD_2210">
         <mdWrap MDTYPE="PREMIS">
            <premis:premis>
              ...
            </premis:premis>
         </mdWrap>
      </techMD>
      ...
  </amdSec>
{code}
Each Bitstream (file) has its own {{amdSec}} within a METS manifest.  So, there will be a separate PREMIS {{techMD}} for each Bitstream within a single Item.

By default, PREMIS metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.techMD = PREMIS, DSPACE-ROLES
{code}

h4. PREMIS Metadata for Bitstream

The following Bitstream information is translated into PREMIS for each DSpace Bitstream (file):

|| Metadata Field || Value ||
| <premis:objectIdentifier> | Contains Bitstream direct URL |
| <premis:objectCategory> | Always set to "File" |
| <premis:fixity> | Contains MD5 Checksum of Bitstream |
| <premis:format> | Contains File Format information of Bistream |
| <premis:originalName> | Contains original name of file |


h3. DSPACE-ROLES Schema

All DSpace Groups and EPeople objects are translated into a custom {{DSPACE-ROLES}} XML Schema.  This XML Schema is a very simple representation of the underlying DSpace database model for Groups and EPeople.  The {{DSPACE-ROLES}} Schemas is generated by DSpace's {{RoleCrosswalk}}.

Only the following DSpace Objects utilize the DSPACE-ROLES Schema in their AIPs:
* Site AIP -- all Groups and EPeople are represented in DSPACE-ROLES Schema
* Community AIP -- only Community-based groups (e.g. {{COMMUNITY_1_ADMIN}}) are represented in DSPACE-ROLES Schema
* Collection AIP -- only Collection-based groups (e.g. {{COLLECTION_2_ADMIN}}, {{COLLECTION_2_SUBMIT}}, etc.) are represented in DSPACE-ROLES Schema

In the METS structure, DSPACE-ROLES metadata always appears within a {{techMD}} inside an {{<mdWrap MDTYPE="OTHER" OTHERMDTYPE="DSPACE-ROLES">}} element. For example:
{code}
  <amdSec ID="amd_2068"> 
      ...
      <techMD ID="techMD_2070">
         <mdWrap MDTYPE="OTHER" OTHERMDTYPE="DSPACE-ROLES">
              ...
         </mdWrap>
      </techMD>
      ...
  </amdSec>
{code}

By default, DSPACE-ROLES metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.techMD = PREMIS, DSPACE-ROLES
{code}


h4. Example of DSPACE-ROLES Schema for a SITE AIP

Below is a general example of the structure of a DSPACE-ROLES XML file, as it would appear in a SITE AIP.

{code}
<DSpaceRoles>
  <Groups>
    <Group ID="1" Name="Administrator">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID="0" Name="Anonymous" />
    <Group ID="70" Name="COLLECTION_hdl:123456789/57_ADMIN">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID="75" Name="COLLECTION_hdl:123456789/57_DEFAULT_READ">
      <MemberGroups>
        <MemberGroup ID="0" Name="Anonymous" />
      </MemberGroups>
    </Group>
    <Group ID="71" Name="COLLECTION_hdl:123456789/57_SUBMIT">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID="72" Name="COLLECTION_hdl:123456789/57_WORKFLOW_STEP_1">
      <MemberGroups>
        <MemberGroup ID="1" Name="Administrator" />
      </MemberGroups>
    </Group>
    <Group ID="73" Name="COLLECTION_hdl:123456789/57_WORKFLOW_STEP_2">
      <MemberGroups>
        <MemberGroup ID="1" Name="Administrator" />
      </MemberGroups>
    </Group>
    <Group ID="8" Name="COLLECTION_hdl:123456789/6703_DEFAULT_READ" />
    <Group ID="9" Name="COLLECTION_hdl:123456789/2_ADMIN">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
  </Groups>
  <People>
    <Person ID="1">
      <Email>bsmith@myu.edu</Email>
      <Netid />
      <FirstName>Bob</FirstName>
      <LastName>Smith</LastName>
      <Language>en</Language>
      <CanLogin />
    </Person>
    <Person ID="2">
      <Email>jjones@myu.edu</Email>
      <Netid />
      <FirstName>Jane</FirstName>
      <LastName>Jones</LastName>
      <Language>en</Language>
      <CanLogin />
    </Person>
  </People>
</DSpaceRoles>
{code}

{info:title=Why are there Group Names with Handles?}You may have noticed several odd looking group names in the above example, where a Handle is embedded in the name (e.g. "COLLECTION_hdl:123456789/57_SUBMIT").  This is a translation of a Group name which included a Community or Collection _Internal ID_ (e.g. "COLLECTION_45_SUBMIT").  Since you are exporting these Groups outside of DSpace, the _Internal ID_ may no longer be valid or be understandable.  Therefore, before export, these Group names are all translated to include an externally understandable identifier, in the form of a Handle.  If you use this AIP to restore your groups later, they will be translated back to the normal DSpace format (i.e. the handle will be translated back to the new _Internal ID_){info}

h4. Example of DSPACE-ROLES Schema for a Community or Collection

Below is a general example of the structure of a DSPACE-ROLES XML file, as it would appear in a Community or Collection AIP.  

This specific example is for a Collection, which has associated Administrator, Submitter, and Workflow approver groups.  In this very simple example, each group only has one Person as a member of it.  Please notice that the Person's information (Name, NetID, etc) is NOT contained in this content (however they are available in the DSPACE-ROLES example for a SITE, as shown above)

{code}
<DSpaceRoles>
  <Groups>
    <Group ID="9" Name="COLLECTION_hdl:123456789/2_ADMIN" Type="ADMIN">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID="13" Name="COLLECTION_hdl:123456789/2_SUBMIT" Type="SUBMIT">
      <Members>
        <Member ID="2" Name="jjones@myu.edu" />
      </Members>
    </Group>
    <Group ID="10" Name="COLLECTION_hdl:123456789/2_WORKFLOW_STEP_1" Type="WORKFLOW_STEP_1">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID="11" Name="COLLECTION_hdl:123456789/2_WORKFLOW_STEP_2" Type="WORKFLOW_STEP_2">
      <Members>
        <Member ID="2" Name="jjones@myu.edu" />
      </Members>
    </Group>
    <Group ID="12" Name="COLLECTION_hdl:123456789/2_WORKFLOW_STEP_3" Type="WORKFLOW_STEP_3">
      <Members>
        <Member ID="1" Name="bsmith@myu.edu" />
      </Members>
    </Group>
  </Groups>
</DSpaceRoles>
{code}



h3. METSRights Schema

All DSpace Policies (permissions on objects) are translated into the [METSRights schema|http://www.loc.gov/standards/rights/METSRights.xsd].  This is different than the above DSPACE-ROLES schema, which only represents Groups and People objects.   Instead, the METSRights schema is used to translate the permission statements (e.g. a group named "Library Admins" has Administrative permissions on a Community named "University Library").  But the METSRights schema doesn't represent who is a member of a particular group (that is defined in the DSPACE-ROLES schema, as described above).

{info:title=METSRights should always be used with DSPACE-ROLES}
The METSRights Schema must be used in conjunction with the DSPACE-ROLES Schema for Groups, People and Permissions to all be restored properly. As mentioned above, the METSRights metadata can only be used to restore permissions (i.e. policies).  The DSPACE-ROLES metadata must also exist if you wish to restore Group or EPeople objects.
{info}

All DSpace Object's AIPs (except for the SITE AIP) utilize the METSRights Schema in order to define what permissions people and groups have on that object.  Although there are several sections to METSRights, DSpace AIPs _only use_ the {{RightsDeclarationMD}} section, as this is what is used to describe rights on an object.

In the METS structure, METSRights metadata always appears within a {{rightsMD}} inside an {{<mdWrap MDTYPE="OTHER" OTHERMDTYPE="METSRIGHTS">}} element. For example:
{code}
  <amdSec ID="amd_2068"> 
      ...
      <rightsMD ID="rightsMD_2074">
         <mdWrap MDTYPE="OTHER" OTHERMDTYPE="METSRIGHTS">
              ...
         </mdWrap>
      </rightsMD>
      ...
  </amdSec>
{code}

By default, METSRights metadata is always included in AIPs. It is controlled by the following configuration in your {{dspace.cfg}}:
{code}
aip.disseminate.rightsMD = DSpaceDepositLicense:DSPACE_DEPLICENSE, \
    CreativeCommonsRDF:DSPACE_CCRDF, CreativeCommonsText:DSPACE_CCTEXT, METSRIGHTS
{code}


h4. Example of METSRights Schema for an Item

An Item AIP will almost always contain several METSRights metadata sections within its METS Manifest.  A separate METSRights metadata section is used to describe the permissions on:
* the Item itself
* each Bundle (group of files) in the Item
* each Bitstream (file) within an Item's bundle

Below is an example of a METSRights sections for a publicly visible Bitstream, Bundle or Item.  Notice it specifies that the "GENERAL PUBLIC" has the permission to DISCOVER or DISPLAY this object.
{code}
<rights:RightsDeclarationMD xmlns:rights="http://cosimo.stanford.edu/sdr/metsrights/" RIGHTSCATEGORY="LICENSED">
  <rights:Context CONTEXTCLASS="GENERAL PUBLIC">
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" />
  </rights:Context>
</rights:RightsDeclarationMD>
{code}


h4. Example of METSRights Schema for a Collection

A Collection AIP contains one METSRights section, which describes the permissions different Groups or People have within the Collection

Below is an example of a METSRights sections for a publicly visible Collection, which also has an Administrator group, a Submitter group, and a group for each of the three DSpace workflow approval steps.  You'll notice that each of the groups is provided with very specific permissions within the Collection.  Submitters & Workflow approvers can "ADD CONTENTS" to a collection (but cannot delete the collection).  Administrators have full rights.
{code}
<rights:RightsDeclarationMD xmlns:rights="http://cosimo.stanford.edu/sdr/metsrights/" RIGHTSCATEGORY="LICENSED">
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COLLECTION_hdl:123456789/2_SUBMIT</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="true" DELETE="false" OTHER="true" OTHERPERMITTYPE="ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COLLECTION_hdl:123456789/2_WORKFLOW_STEP_3</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="true" DELETE="false" OTHER="true" OTHERPERMITTYPE="ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COLLECTION_hdl:123456789/2_WORKFLOW_STEP_2</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="true" DELETE="false" OTHER="true" OTHERPERMITTYPE="ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COLLECTION_hdl:123456789/2_WORKFLOW_STEP_1</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="true" DELETE="false" OTHER="true" OTHERPERMITTYPE="ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COLLECTION_hdl:123456789/2_ADMIN</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" COPY="true" DUPLICATE="true" MODIFY="true" DELETE="true" PRINT="true" OTHER="true" OTHERPERMITTYPE="ADMIN" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="GENERAL PUBLIC">
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" />
  </rights:Context>
</rights:RightsDeclarationMD>
{code}

h4. Example of METSRights Schema for a Community

A Community AIP contains one METSRights section, which describes the permissions different Groups or People have within that Community.

Below is an example of a METSRights sections for a publicly visible Community, which also has an Administrator group.  As you'll notice, this content looks very similar to the Collection METSRights section (as described above)

{code}
<rights:RightsDeclarationMD xmlns:rights="http://cosimo.stanford.edu/sdr/metsrights/" RIGHTSCATEGORY="LICENSED">
  <rights:Context CONTEXTCLASS="MANAGED_GRP">
    <rights:UserName USERTYPE="GROUP">COMMUNITY_hdl:123456789/10_ADMIN</rights:UserName>
    <rights:Permissions DISCOVER="true" DISPLAY="true" COPY="true" DUPLICATE="true" MODIFY="true" DELETE="true" PRINT="true" OTHER="true" OTHERPERMITTYPE="ADMIN" />
  </rights:Context>
  <rights:Context CONTEXTCLASS="GENERAL PUBLIC">
    <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" />
  </rights:Context>
</rights:RightsDeclarationMD>
{code}