All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
Unsupported Release
This documentation relates to an old, unsupported version of DSpace, version 1.7.x. Looking for another version? See all documentation.
As of January 2014, the DSpace 1.7.x platform is no longer supported. We recommend upgrading to a more recent version of DSpace.
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:
COMMUNITY_<ID>_ADMIN
group).COLLECTION_<ID>_ADMIN
, COLLECTION_<ID>_SUBMIT
, etc.).Notes:
What is NOT in AIPs
DSpace Site configurations ([dspace]/config/ directory) or customizations are not described in AIPs
This METS Structure is based on the structure decided for the original AipPrototype, developed as part of the PLEDGE project.
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, such as dspace67075091976862014717971209717749394363
.mets/metsHdr
element
@LASTMODDATE
last-modified date for a DSpace Item, or nothing for other objects.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)mets/dmdSec
element
dmdSec
elements are included for all AIPs:
mets/dmdSec/mdWrap@MDTYPE="MODS"
)mets/dmdSec/mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DIM"
)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. (mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DSpaceDepositLicense"
)CreativeCommonsRDF
If the object is an Item with a Creative Commons license expressed in RDF, it is included here. (mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="CreativeCommonsRDF"
)CreativeCommonsText
If the object is an Item with a Creative Commons license in plain text, it is included here. (mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="CreativeCommonsText"
)sourceMD
elements - recorded twice, once in DSpace native format, once in PREMIS:AIP-TECHMD
" (see Metadata in METS section below for details)digiprovMD
mets/amdSec
elements - technical metadata for each of an Items's Bitstreams, both in PREMIS and DIM formats
techMD
element - PREMIS technical metadata, expanded from SIP, for each of an Item's Bitstreams.sourceMD
element, type is AIP-TECHMD.
name
(dc.title
)description
(dc.descripton
)userFormatDescription
(dc.format
)dc.format.medium
)
mets/fileSec
element
fileGrp
. The fileGrp
has a @USE
attribute which corresponds to the Bundle name.file
elements under fileGrp
.mets/fileSec/fileGrp/file
element
@SIZE
to length of the bitstream. There is a redundant value in the techMD but it is more accessible here.@MIMETYPE
, @CHECKSUM
, @CHECKSUMTYPE
to corresponding bitstream values. There is redundant info in the techMD. (For DSpace, the @CHECKSUMTYPE="MD5"
)@SEQ
to bitstream's SequenceID if it has one.fileSec
with one fileGrp
child of @USE="LOGO"
.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.structMap
for the fptr
reference to this logo file.mets/structMap
- Primary structure map, @LABEL="DSpace Object", @TYPE="LOGICAL"
div
with @TYPE="DSpace Object Contents"
.
div
with @TYPE="DSpace BITSTREAM"
. Each Bitstream div
has a single fptr
element which references the bitstream location.structMap/div/fptr
(i.e. directly under the div
with @TYPE="DSpace Object Contents"
)div
with @TYPE="DSpace Object Contents"
.
div
with @TYPE="DSpace ITEM"
. Each Item div
has up to two child mptr
elements:
@LOCTYPE="HANDLE"
, and @xlink:href
value is the raw Handle.@LOCTYPE="URL"
, and @xlink:href
value is a relative link to the AIP file on the local filesystem.fptr
reference to it in the very first div
.div
with @TYPE="DSpace Object Contents"
.
div
with @TYPE="DSpace COMMUNITY"
. Each Community div
has up to two mptr
elements:
@LOCTYPE="HANDLE"
, and @xlink:href
value is the raw Handle.@LOCTYPE="URL"
, and @xlink:href
value is a relative link to the AIP file on the local filesystem.div
with @TYPE="DSpace COLLECTION"
. Each Collection div
has up to two mptr
elements:
@LOCTYPE="HANDLE"
, and @xlink:href
value is the raw Handle.@LOCTYPE="URL"
, and @xlink:href
value is a relative link to the AIP file on the local filesystem.fptr
reference to it in the very first div
.div
with @TYPE="DSpace Object Contents"
.
div
with @TYPE="DSpace COMMUNITY"
. Each Item div
has up to two child mptr
elements:
@LOCTYPE="HANDLE"
, and @xlink:href
value is the raw Handle.@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"
div
element which has the unique attribute value TYPE="AIP Parent Link"
to identify it as the older of the parent pointer.
mptr
element whose xlink:href
attribute value is the raw Handle of the parent object, e.g. 1721.1/4321
.The following tables describe how various metadata schemas are populated (via DSpace Crosswalks) in the METS file for an AIP.
DIM Schema 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:
<dmdSec ID="dmdSec_2190"> <mdWrap MDTYPE="OTHER" OTHERMDTYPE="DIM"> ... </mdWrap> </dmdSec>
By default, DIM metadata is always included in AIPs. It is controlled by the following configuration in your dspace.cfg
:
aip.disseminate.dmd = MODS, DIM
As all DSpace Items already have user-assigned DIM (essentially Qualified Dublin Core) metadata fields, those fields are just exported into the DIM Schema within the METS file.
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 |
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 |
For the Site Object, the following fields are translated to the DIM schema:
Metadata Field |
Value |
||
---|---|---|---|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="dca267f2-5521-4918-8106-fbf8b1d52e1e"><ac:plain-text-body><![CDATA[ |
dc.identifier.uri |
Handle of Site (format: |
]]></ac:plain-text-body></ac:structured-macro> |
dc.title |
Name of Site (from dspace.cfg 'dspace.name' config) |
By default, all DSpace descriptive metadata (DIM) is also translated into the MODS Schema 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:
<dmdSec ID="dmdSec_2189"> <mdWrap MDTYPE="MODS"> ... </mdWrap> </dmdSec>
By default, MODS metadata is always included in AIPs. It is controlled by the following configuration in your dspace.cfg
:
aip.disseminate.dmd = MODS, DIM
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.
The AIP Technical Metadata Schema is a way to translate technical metadata about a DSpace object into the DIM Schema. 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:
<amdSec ID="amd_2191"> ... <sourceMD ID="sourceMD_2198"> <mdWrap MDTYPE="OTHER" OTHERMDTYPE="AIP-TECHMD"> ... </mdWrap> </sourceMD> ... </amdSec>
By default, AIP-TECHMD metadata is always included in AIPs. It is controlled by the following configuration in your dspace.cfg
:
aip.disseminate.sourceMD = AIP-TECHMD
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 |
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()) |
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) |
Metadata Field |
Value |
---|---|
dc.identifier.uri |
Handle of Community |
dc.relation.isPartOf |
Handle of Parent Community (as a URN) |
Metadata Field |
Value |
||
---|---|---|---|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f58cad1c-2fd3-47c2-8ebd-5a9212db3fcd"><ac:plain-text-body><![CDATA[ |
dc.identifier.uri |
Site Handle (format: |
]]></ac:plain-text-body></ac:structured-macro> |
At this point in time, the PREMIS Schema 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 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:
<amdSec ID="amd_2209"> ... <techMD ID="techMD_2210"> <mdWrap MDTYPE="PREMIS"> <premis:premis> ... </premis:premis> </mdWrap> </techMD> ... </amdSec>
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
:
aip.disseminate.techMD = PREMIS, DSPACE-ROLES
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 |
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:
COMMUNITY_1_ADMIN
) are represented in DSPACE-ROLES SchemaCOLLECTION_2_ADMIN
, COLLECTION_2_SUBMIT
, etc.) are represented in DSPACE-ROLES SchemaIn the METS structure, DSPACE-ROLES metadata always appears within a techMD
inside an <mdWrap MDTYPE="OTHER" OTHERMDTYPE="DSPACE-ROLES">
element. For example:
<amdSec ID="amd_2068"> ... <techMD ID="techMD_2070"> <mdWrap MDTYPE="OTHER" OTHERMDTYPE="DSPACE-ROLES"> ... </mdWrap> </techMD> ... </amdSec>
By default, DSPACE-ROLES metadata is always included in AIPs. It is controlled by the following configuration in your dspace.cfg
:
aip.disseminate.techMD = PREMIS, DSPACE-ROLES
Below is a general example of the structure of a DSPACE-ROLES XML file.
<DSpaceRoles> <Groups> <Group ID="1" Name="Administrator"> <Members> <Member ID="1" Name="tdonohue@duraspace.org" /> </Members> </Group> <Group ID="0" Name="Anonymous" /> <Group ID="70" Name="COLLECTION_hdl:123456789/57_ADMIN"> <Members> <Member ID="1" Name="tdonohue@duraspace.org" /> </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="tdonohue@duraspace.org" /> </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="74" Name="COLLECTION_hdl:123456789/57_WORKFLOW_STEP_3"> <MemberGroups> <MemberGroup ID="0" Name="Anonymous" /> </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="tdonohue@duraspace.org" /> </Members> </Group> </Groups> <People> <Person ID="1"> <Email>tdonohue@duraspace.org</Email> <Netid /> <FirstName>Tim</FirstName> <LastName>Donohue</LastName> <Language>en</Language> <CanLogin /> </Person> </People> </DSpaceRoles>
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)