Message-ID: <742898899.10069.1558514335955.JavaMail.j2ee-wiki@duraspace-app01.managed.contegix.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10068_696326306.1558514335955" ------=_Part_10068_696326306.1558514335955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html DSpace AIP Format

DSpace AIP Format

=20 =20

Makeup and Definition = of AIPs

AIPs only store the Latest Version of Items

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 n= ot yet compatible with AIP Backup & Restore. Using the= m together may result in accidental data loss.  Currently the= AIPs that DSpace generates only store the latest version of an It= em.  Therefore, past versions of Items will always be lost when you pe= rform a restore / replace using AIP tools.

AIPs are Arc= hival Information Packages.

General AIP Structu= re / Examples

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

Some examples include:

Notes:

What is NOT in AIPs

Customizing Wh= at Is Stored in Your AIPs

If you choose, you can customize exactly what information is stored in y= our AIPs. However, you should be aware that you can only restore informatio= n which is stored within your AIPs. If you choose to remove information fro= m your AIPs, you will be unable to restore it later on (unless you are also= backing up your entire DSpace database and assetstore folder).

AIP Recommendations

It is recommended to minimally use the default settings when generating = AIPs. DSpace can only restore information that is included within an AIP. T= herefore, if you choose to no longer include some information in an AIP, DS= pace will no longer be able to restore that information from an AIP backup<= /p>

There are two ways to go about customizing your AIP format:

  1. You can customize your dspace.cfg= settings pertaining to AIP generation. These configurations will allow= you to specify exactly which DSpace Crosswalks will be called when generat= ing the AIP METS manifest.
  2. You can export your AIPs using one of the specia= l options/flags.

AIP Details: METS Struc= ture

This METS Structure is based on the structure decided for the original <= a href=3D"/display/DSPACE/AipPrototype">AipPrototype, developed as part= of the MIT & UCSD PLEDGE project.

Metadata in METS

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

DIM (DSpac= e Intermediate Metadata) Schema

DIM Schema is= essentially a way of representing DSpace internal metadata structure in XM= L. DSpace's internal metadata is very similar to a Qualified Dublin Core in= its structure, and is primarily meant for descriptive metadata. However, D= Space's metadata allows for custom elements, qualifiers or schemas to be cr= eated (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 n= ormal Qualified Dublin Core. So, the DIM Schema must be able to express met= adata schemas, elements or qualifiers which may or may not exist within Qua= lified Dublin Core.

In the METS structure, DIM metadata always appears within a dmdSec= inside an <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D"DIM">= element. For example:

=20
  <d=
mdSec ID=3D"dmdSec_2190">=20
     <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D"DIM">
      ...
     </mdWrap>
  </dmdSec>
=20

By default, DIM metadata is always included in AIPs. It is controlled by= the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.dmd =3D MODS, DIM
=20

DIM Descrip= tive Elements for Item objects

As all DSpace Items already have user-assigned DIM (essentially Qualifie= d Dublin Core) metadata fields, those fields are just exported into the DIM Schema within t= he METS file.

DIM D= escriptive Elements for Collection objects

For Collections, the following fields are translated to the DIM schema:<= /p>

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

DIM De= scriptive Elements for Community objects

For Communities, the following fields are translated to the DIM schema:<= /p>

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

DIM Descrip= tive Elements for Site objects

For the Site Object, the following fields are translated to the DIM sche= ma:

Metadata Field

Value

dc.identifier.uri

Handle of Site (format: [handle_prefix]= /0)

dc.title

Name of Site (from dspace.cfg 'dspace.name' c= onfig)

MODS Schema

By default, all DSpace descriptive metadata (DIM) is also translated int= o the MODS Schema by utilizing DSpace's MODSDissemin= ationCrosswalk. DSpace's DIM to MODS crosswalk is defined within you= r [dspace]/config/crosswalks/mods.properties configuration fil= e. 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 dmdSe= c inside an <mdWrap MDTYPE=3D"MODS"> element. For= example:

=20
  <d=
mdSec ID=3D"dmdSec_2189">=20
     <mdWrap MDTYPE=3D"MODS">
      ...
     </mdWrap>
  </dmdSec>
=20

By default, MODS metadata is always included in AIPs. It is controlled b= y the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.dmd =3D MODS, DIM
=20

The MODS metadata is included within your AIP to support interoperabilit= y. It provides a way for other systems to interact with or ingest the AIP w= ithout 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 t= o 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. Onl= y if no DIM metadata is found, will the MODS metadata be used during a rest= ore.

AIP Techn= ical Metadata Schema (AIP-TECHMD)

The AIP Technical Metadata Schema is a way to translate technical metada= ta about a DSpace object into the DIM Schema. It is kept separate from DIM as it is conside= red technical metadata rather than descriptive metadata.

In the METS structure, AIP-TECHMD metadata always appears within a sourceMD inside an <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D= "AIP-TECHMD"> element. For example:

=20
  <a=
mdSec ID=3D"amd_2191">=20
      ...
      <sourceMD ID=3D"sourceMD_2198">
         <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D"AIP-TECHMD">
         ...
         </mdWrap>
      </sourceMD>
      ...
  </amdSec>
=20

By default, AIP-TECHMD metadata is always included in AIPs. It is contro= lled by the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.sourceMD =3D AIP-TECHMD
=20

AIP Technical Metada= ta 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

=

AIP Technical M= etadata for Bitstream

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 defa= ult)

dc.format.internal

Whether Format is internal (necessary to recr= eate Format during restore, if the format isn't know to DSpace by default)<= /p>

  • Outstanding Question: Why are we recording the file format support stat= us? That's a DSpace property, rather than an Item property. Do DSpace insta= nces rely on objects to tell them their support status?
    • Possible answer (from Larry Stone): Format support and other properties= of the BitstreamFormat are recorded here in case the Item is restored in a= n 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

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 link= ed to (Handle URN of each non-owner)

AIP Technical M= etadata for Community

Metadata Field

Value

dc.identifier.uri

Handle of Community

dc.relation.isPartOf

Handle of Parent Community (as a URN= )

AIP Technical Metada= ta for Site

Metadata Field

Value

dc.identifier.uri

Site Handle (format: [handle_prefix]/0<= /code>)

PREMIS Schema

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 tec= hMD inside an <mdWrap MDTYPE=3D"PREMIS"> element.= PREMIS metadata is always wrapped withn a <premi= s:premis> element. For example:

=20
  <a=
mdSec ID=3D"amd_2209">=20
      ...
      <techMD ID=3D"techMD_2210">
         <mdWrap MDTYPE=3D"PREMIS">
            <premis:premis>
              ...
            </premis:premis>
         </mdWrap>
      </techMD>
      ...
  </amdSec>
=20

Each Bitstream (file) has its own amdSec within a METS mani= fest. So, there will be a separate PREMIS techMD for each Bits= tream within a single Item.

By default, PREMIS metadata is always included in AIPs. It is controlled= by the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.techMD =3D PREMIS, DSPACE-ROLES
=20

PREMIS Metadata for B= itstream

The following Bitstream information is translated into PREMIS for each D= Space 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<= /p>

<premis:originalName>

Contains original name of file

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 represent= ation of the underlying DSpace database model for Groups and EPeople. The <= code>DSPACE-ROLES Schemas is generated by DSpace's RoleCrosswa= lk.

Only the following DSpace Objects utilize the DSPACE-ROLES Schema in the= ir AIPs:

In the METS structure, DSPACE-ROLES metadata always appears within a techMD inside an <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D= "DSPACE-ROLES"> element. For example:

=20
  <a=
mdSec ID=3D"amd_2068">=20
      ...
      <techMD ID=3D"techMD_2070">
         <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D"DSPACE-ROLES">
              ...
         </mdWrap>
      </techMD>
      ...
  </amdSec>
=20

By default, DSPACE-ROLES metadata is always included in AIPs. It is cont= rolled by the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.techMD =3D PREMIS, DSPACE-ROLES
=20

Example o= f 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.

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

Why are there Group Names with Handles?

You may have noticed several odd looking group names in the above exampl= e, where a Handle is embedded in the name (e.g. "COLLECTION_hdl:123456789/5= 7_SUBMIT"). This is a translation of a Group name which included a Communit= y or Collection Internal ID (e.g. "COLLECTION_45_SUBMIT"). Since y= ou are exporting these Groups outside of DSpace, the Internal ID m= ay no longer be valid or be understandable. Therefore, before export, these= Group names are all translated to include an externally understandable ide= ntifier, in the form of a Handle. If you use this AIP to restore your group= s later, they will be translated back to the normal DSpace format (i.e. the= handle will be translated back to the new Internal ID).

Orphaned Groups are Renamed on Export

If a Group name includes a Community or Collection Internal ID = (e.g. "COLLECTION_45_SUBMIT"), and that Community or Collection no longer e= xists, then the Group is considered "Orphaned".

  • In 1.8.2 and above, the Group is renamed using the following format: "O= RPHANED_[object-type]_GROUP_[obj-id]_[group-type]" (e.g. "ORPHANED_COLLECTI= ON_GROUP_10_ADMIN").
  • Prior to 1.8.2, the Group was renamed with a random key: "GROUP_[random= -hex-key]_[object-type]_[group-type]" (e.g. "GROUP_123eb3a_COLLECTION_ADMIN= "). This old format was discontinued as giving the groups a randomly ge= nerated name caused the SITE AIP to have a different checksum every time it= was regenerated (see DS-1120).

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 t= ranslation, 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.=

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 Administ= rator, 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 (h= owever they are available in the DSPACE-ROLES example for a SITE, as shown = above)

=20
<DSp=
aceRoles>
  <Groups>
    <Group ID=3D"9" Name=3D"COLLECTION_hdl:123456789/2_ADMIN" Type=3D"AD=
MIN">
      <Members>
        <Member ID=3D"1" Name=3D"bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID=3D"13" Name=3D"COLLECTION_hdl:123456789/2_SUBMIT" Type=3D"=
SUBMIT">
      <Members>
        <Member ID=3D"2" Name=3D"jjones@myu.edu" />
      </Members>
    </Group>
    <Group ID=3D"10" Name=3D"COLLECTION_hdl:123456789/2_WORKFLOW_STEP_1"=
 Type=3D"WORKFLOW_STEP_1">
      <Members>
        <Member ID=3D"1" Name=3D"bsmith@myu.edu" />
      </Members>
    </Group>
    <Group ID=3D"11" Name=3D"COLLECTION_hdl:123456789/2_WORKFLOW_STEP_2"=
 Type=3D"WORKFLOW_STEP_2">
      <Members>
        <Member ID=3D"2" Name=3D"jjones@myu.edu" />
      </Members>
    </Group>
    <Group ID=3D"12" Name=3D"COLLECTION_hdl:123456789/2_WORKFLOW_STEP_3"=
 Type=3D"WORKFLOW_STEP_3">
      <Members>
        <Member ID=3D"1" Name=3D"bsmith@myu.edu" />
      </Members>
    </Group>
  </Groups>
</DSpaceRoles>
=20

METSRights Schema

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 statem= ents (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 DS= PACE-ROLES schema, as described above).

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 m= entioned above, the METSRights metadata can only be used to restore permiss= ions (i.e. DSpace policies). The DSPACE-ROLES metadata must also exist if y= ou wish to restore the actual Group or EPeople objects to which those permi= ssions apply.

All DSpace Object's AIPs (except for the SITE AIP) utilize the METSRight= s Schema in order to define what permissions people and groups have on that= object. Although there are several sections to the METSRights Schema, DSpa= ce AIPs only use the <RightsDeclarationMD> sect= ion, 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=3D"OTHER" OTHERMDTYPE=3D= "METSRIGHTS"> element. For example:

=20
  <a=
mdSec ID=3D"amd_2068">=20
      ...
      <rightsMD ID=3D"rightsMD_2074">
         <mdWrap MDTYPE=3D"OTHER" OTHERMDTYPE=3D"METSRIGHTS">
              ...
         </mdWrap>
      </rightsMD>
      ...
  </amdSec>
=20

By default, METSRights metadata is always included in AIPs. It is contro= lled by the following configuration in your dspace.cfg:

=20
aip.dis=
seminate.rightsMD =3D DSpaceDepositLicense:DSPACE_DEPLICENSE, \
    CreativeCommonsRDF:DSPACE_CCRDF, CreativeCommonsText:DSPACE_CCTEXT, MET=
SRIGHTS
=20

Example of ME= TSRights Schema for an Item

An Item AIP will almost always contain several METSRights metadata secti= ons within its METS Manifest. A separate METSRights metadata section is use= d 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 Bits= tream, Bundle or Item. Notice it specifies that the "GENERAL PUBLIC" has th= e permission to DISCOVER or DISPLAY this object.

=20
<rig=
hts:RightsDeclarationMD xmlns:rights=3D"http://cosimo.stanford.edu/sdr/mets=
rights/" RIGHTSCATEGORY=3D"LICENSED">
  <rights:Context CONTEXTCLASS=3D"GENERAL PUBLIC">
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"fal=
se" DELETE=3D"false" />
  </rights:Context>
</rights:RightsDeclarationMD>
=20

As of DSpace 3, DSpace policies/permissions may also have a "start-date"= or "end-date" (to support Embarg= o functionality). Such a policy on an Item may look like this. &nb= sp;Notice it specifies that the "GENERAL PUBLIC" has the permission to DISC= OVER or DISPLAY this object starting on 2015-01-01, whil= e the Group "Staff" has permission to DISCOVER or DISPLAY this object = until 2015-01-01.

=20
<rig=
hts:RightsDeclarationMD xmlns:rights=3D"http://cosimo.stanford.edu/sdr/mets=
rights/" RIGHTSCATEGORY=3D"LICENSED">
  <rights:Context CONTEXTCLASS=3D"GENERAL PUBLIC" start-date=3D"2015-01-=
01" in-effect=3D"false">
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"fal=
se" DELETE=3D"false" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP" end-date=3D"2015-01-01" i=
n-effect=3D"true">
    <rights:UserName USERTYPE=3D"GROUP">Staff</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"fal=
se" DELETE=3D"false" />
  </rights:Context>
</rights:RightsDeclarationMD>
=20

Example = of METSRights Schema for a Collection

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

Below is an example of a METSRights sections for a publicly visible Coll= ection, which also has an Administrator group, a Submitter group, and a gro= up 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 C= ollection. Submitters & Workflow approvers can "ADD CONTENTS" to a coll= ection (but cannot delete the collection). Administrators have full rights.=

=20
<rig=
hts:RightsDeclarationMD xmlns:rights=3D"http://cosimo.stanford.edu/sdr/mets=
rights/" RIGHTSCATEGORY=3D"LICENSED">
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COLLECTION_hdl:123456789/2_SU=
BMIT</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"tru=
e" DELETE=3D"false" OTHER=3D"true" OTHERPERMITTYPE=3D"ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COLLECTION_hdl:123456789/2_WO=
RKFLOW_STEP_3</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"tru=
e" DELETE=3D"false" OTHER=3D"true" OTHERPERMITTYPE=3D"ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COLLECTION_hdl:123456789/2_WO=
RKFLOW_STEP_2</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"tru=
e" DELETE=3D"false" OTHER=3D"true" OTHERPERMITTYPE=3D"ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COLLECTION_hdl:123456789/2_WO=
RKFLOW_STEP_1</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"tru=
e" DELETE=3D"false" OTHER=3D"true" OTHERPERMITTYPE=3D"ADD CONTENTS" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COLLECTION_hdl:123456789/2_AD=
MIN</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" COPY=3D"true"=
 DUPLICATE=3D"true" MODIFY=3D"true" DELETE=3D"true" PRINT=3D"true" OTHER=3D=
"true" OTHERPERMITTYPE=3D"ADMIN" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"GENERAL PUBLIC">
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"fal=
se" DELETE=3D"false" />
  </rights:Context>
</rights:RightsDeclarationMD>
=20

Example o= f METSRights Schema for a Community

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

Below is an example of a METSRights sections for a publicly visible Comm= unity, which also has an Administrator group. As you'll notice, this conten= t looks very similar to the Collection METSRights section (as described abo= ve)

=20
<rig=
hts:RightsDeclarationMD xmlns:rights=3D"http://cosimo.stanford.edu/sdr/mets=
rights/" RIGHTSCATEGORY=3D"LICENSED">
  <rights:Context CONTEXTCLASS=3D"MANAGED_GRP">
    <rights:UserName USERTYPE=3D"GROUP">COMMUNITY_hdl:123456789/10_AD=
MIN</rights:UserName>
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" COPY=3D"true"=
 DUPLICATE=3D"true" MODIFY=3D"true" DELETE=3D"true" PRINT=3D"true" OTHER=3D=
"true" OTHERPERMITTYPE=3D"ADMIN" />
  </rights:Context>
  <rights:Context CONTEXTCLASS=3D"GENERAL PUBLIC">
    <rights:Permissions DISCOVER=3D"true" DISPLAY=3D"true" MODIFY=3D"fal=
se" DELETE=3D"false" />
  </rights:Context>
</rights:RightsDeclarationMD>
=20
------=_Part_10068_696326306.1558514335955--
https://wiki.duraspace.org/exportword?pageId=45548214
wiki.duraspace.org
crawl=CC-MAIN-2019-22
74853
application/http; msgtype=response
sha1:U7ZUPW4CIZUOEDACCR3MBB7H52NZJIRE
<urn:uuid:0595a03a-f58c-43c0-b34a-a35aab59008d>
2019-05-22T08:38:56Z
199.119.127.15
message/rfc822
sha1:7QY5TQM3GQVFHW73D5CHVEMJPQIJ472F
<urn:uuid:8f793579-4646-40ae-9427-6f6cb4387a77>
https://wiki.duraspace.org/exportword?pageId=45548214
response
<urn:uuid:b3dc19d1-0c79-4eee-98d2-59732328b7ee>
isPartOf: CC-MAIN-2019-22
publisher: Common Crawl
description: Wide crawl of the web for May 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-171-61-111.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/