If you are using the new XMLUI-only Item Level Versioning functionality (disabled by default), you must be aware that this "Item Level Versioning" feature is not yet compatible with AIP Backup & Restore. Using them together may result in accidental data loss. Currently the AIPs that DSpace generates only store the latest version of an Item. Therefore, past versions of Items will always be lost when you perform a restore / replace using AIP tools. |
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
If you choose, you can customize exactly what information is stored in your AIPs. However, you should be aware that you can only restore information which is stored within your AIPs. If you choose to remove information from your AIPs, you will be unable to restore it later on (unless you are also backing up your entire DSpace database and assetstore folder).
It is recommended to minimally use the default settings when generating AIPs. DSpace can only restore information that is included within an AIP. Therefore, if you choose to no longer include some information in an AIP, DSpace will no longer be able to restore that information from an AIP backup |
There are two ways to go about customizing your AIP format:
dspace.cfg
settings pertaining to AIP generation. These configurations will allow you to specify exactly which DSpace Crosswalks will be called when generating the AIP METS manifest.This METS Structure is based on the structure decided for the original AipPrototype, developed as part of the MIT & UCSD 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, 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.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)dmdSec
elements are included for all AIPs:mets/dmdSec/mdWrap@MDTYPE="MODS"
). See #MODS Schema section below for more information.mets/dmdSec/mdWrap@MDTYPE="OTHER",@OTHERMDTYPE="DIM"
. See #DIM (DSpace Intermediate Metadata) Schema section below for more information.dmdSec
elements may exist which describe the Item Template for that Collection. Since an Item template is not an actual Item (i.e. it only includes metadata), it is stored within the Collection AIP. The Item Template's dmdSec
elements will be referenced by a div @TYPE="DSpace ITEM Template"
in the METS structMap
.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)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.mets/fileSec
elementfileGrp
. The fileGrp
has a @USE
attribute which corresponds to the Bundle name.file
elements under fileGrp
.mets/fileSec/fileGrp/file
elements@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"
at all times)@SEQ
to bitstream's SequenceID if it has one.@ADMID
to the list of <amdSec>
element(s) which describe this bitstream.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 (e.g. @ADMID
) 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 ITEM Template"
within the very first div
. This div @TYPE="DSpace ITEM Template"
must have a @DMDID
specified, which links to the dmdSec
element(s) that contain the metadata for the Item Template.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 |
---|---|
dc.identifier.uri | Handle of Site (format: |
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 |
dc.description | Bitstream's description |
dc.format | Bitstream Format Description |
dc.format.medium | Short Name of Format |
dc.format.mimetype | MIMEType of Format |
dc.format.supportlevel | System Support Level for Format (necessary to recreate Format during restore, if the format isn't know to DSpace by default) |
dc.format.internal | Whether Format is internal (necessary to recreate Format during restore, if the format isn't know to DSpace by default) |
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 |
---|---|
dc.identifier.uri | Site Handle (format: |
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, as it would appear in a SITE AIP.
<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>bsmith</Netid> <FirstName>Bob</FirstName> <LastName>Smith</LastName> <Language>en</Language> <CanLogin /> </Person> <Person ID="2"> <Email>jjones@myu.edu</Email> <FirstName>Jane</FirstName> <LastName>Jones</LastName> <Language>en</Language> <CanLogin /> <SelfRegistered /> </Person> </People> </DSpaceRoles> |
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). |
If a Group name includes a Community or Collection Internal ID (e.g. "COLLECTION_45_SUBMIT"), and that Community or Collection no longer exists, then the Group is considered "Orphaned".
The reasoning is that we were unable to translate an Internal ID into an External ID (i.e. Handle). If we are unable to do that translation, re-importing or restoring a group with an old internal ID could cause conflicts or instability in your DSpace system. In order to avoid such conflicts, these groups are renamed using a random, unique key. |
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)
<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> |
All DSpace Policies (permissions on objects) are translated into the METSRights schema. 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).
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. DSpace policies). The DSPACE-ROLES metadata must also exist if you wish to restore the actual Group or EPeople objects to which those permissions apply. |
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 the METSRights Schema, 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:
<amdSec ID="amd_2068"> ... <rightsMD ID="rightsMD_2074"> <mdWrap MDTYPE="OTHER" OTHERMDTYPE="METSRIGHTS"> ... </mdWrap> </rightsMD> ... </amdSec> |
By default, METSRights metadata is always included in AIPs. It is controlled by the following configuration in your dspace.cfg
:
aip.disseminate.rightsMD = DSpaceDepositLicense:DSPACE_DEPLICENSE, \ CreativeCommonsRDF:DSPACE_CCRDF, CreativeCommonsText:DSPACE_CCTEXT, METSRIGHTS |
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:
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.
<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> |
As of DSpace 3, DSpace policies/permissions may also have a "start-date" or "end-date" (to support Embargo functionality). Such a policy on an Item may look like this. Notice it specifies that the "GENERAL PUBLIC" has the permission to DISCOVER or DISPLAY this object starting on 2015-01-01, while the Group "Staff" has permission to DISCOVER or DISPLAY this object until 2015-01-01.
<rights:RightsDeclarationMD xmlns:rights="http://cosimo.stanford.edu/sdr/metsrights/" RIGHTSCATEGORY="LICENSED"> <rights:Context CONTEXTCLASS="GENERAL PUBLIC" start-date="2015-01-01" in-effect="false"> <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" /> </rights:Context> <rights:Context CONTEXTCLASS="MANAGED_GRP" end-date="2015-01-01" in-effect="true"> <rights:UserName USERTYPE="GROUP">Staff</rights:UserName> <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" /> </rights:Context> </rights:RightsDeclarationMD> |
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.
<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> |
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)
<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> |