AIP Details: METS, MODS, PREMIS Usage – Rob Wolfe's Comments

METS Usage

```
mets
```
element
- ```
@ID
```
  SHOULD be required
  - @IDs should be used wherever available, I'll put a note about forming IDs in the profile spec.
    OK, but how unique does the ID have to be, just within the document or amongst all other AIP documentes? --lcs
    I can't imagine a scenario where we would reference an ID within a METS document from without that document, except for perhaps the
    mets@ID
    . I would say the
    mets@ID
    should be unique amongst all AIP documents, but the other IDs should just be unique within the document.
```
mets/metsHdr
```
element
- ```
@createdate
```
  and
```
@lastmoddate
```
  - mets defines these attributes as describing the METS document itself, we use them to describe the AIP, which sometimes we think of as the METS document, but more often think of as the 'package' – i.e. the METS document and all the files. I don't have a problem with the use Larry put forth, but we need to mention it in a prolife. I wonder if these dates shouldn't rather be in a techMD section, or maybe both.
```
mets/dmdSec
```
- ```
@OTHERMDTYPE
```
  - We should require mets/dmdSec@OTHERMDTYPE if @MDTYPE = "OTHER"
```
mets/amdSec
```
– Item specific metadata encoded in DIM
- ```
mets/amdSec/sourceMD
```
  was
```
mets/amdSec/techMD
```
  - Put Item/Collection/Community Technical Metadata into
    sourceMD
    section. Just replace parent
    techMD
    element with
    sourceMD
    (attributes remain the same) This technical metadata correctly falls under the usage of the sourceMD element.
  - owning collection handle (dc.relation.isReferencedBy)
    - "isReferencedBy" – Is this the right way to characterize the Item->Collection->Community relationships? Should we use "ispartof"? Will there be more than one of these elements for Items that are cross-listed?
      Yeah, "ispartof" makes more sense. Currently it only mentions the collection that directly owns the Item. Even that is only meaningful when restoring an archive from AIPs, but it wouldn't hurt to have the mapped collections listed to, using the "isReferenecedBy" qualifier. --lcs
      I agree, owning collection recorded using "ispartof", cross listed collections recorded using "isReferencedBy".
  - This Item specific metadata should be expressed using the PREMIS Data Dictionary. This PREMIS expression need not replace the DIM/DC expression.
    First I'll need a PREMIS crosswalk defined for Items, there is currently only one for bitstreams. --lcs
    I'm trying to upload the xml example, but it won't let me.
- ```
mets/amdSec/rightsMD
```
  - There should be a rightsMD section that lists or references both the DSpace Distribution and Creative Commons Licenses for the item.
- ```
mets/amdSec/digprovMD
```
  - In AIPs we should reference the Event History for objects (perhaps via the URI of the object as recorded by the Event History System). Our goal is not to include the whole history in the AIP but give holders of the AIP a means to acquire the history.
```
mets/amdSec
```
Bitstream specific metadata encoded in PREMIS and DIM
- In samples linke from PREMIS Usage section, I've translated more of the DIM elements to the PREMIS expression. We should not however do away with the DIM elements. I can't make the extra format metadata (support, known, medium) fit into PREMIS and this metadata is worth preserving. It is useful to other DSpace instances and therefore should remain in a DSpace format. We should, however, translate as much of this information as we can to a more interoperable format like PREMIS for sharing with non-DSpace systems.
```
mets/fileSec
```
- ```
mets/fileSec/fileGrp
```
  - Did the "ORIGINAL" bundle get renamed "CONTENT"?
  - mets/fileSec/fileGrp/file
    - file@CREATED
      and
      file@SIZE
      - The DSpace SIP calls for the use of
        
        @CREATED
        
        for the file element, AIP examples do not use
        
        @CREATED
        
        , but do use
        
        @SIZE
        
        , which is not recommended by SIP.
```
mets/structMap
```
- ```
mets/structMap/div
```
  - mets/structMap/div/mptr
    - In Collection and Community AIPs shouldn't fptrs by accompanied by mptrs? fptrs point to item handles, but mptrs should point to METS AIP documents for these items.
      Right now collections aggregate Items via the
      FLocat
      element which contains an
      @xlink:href
      that contains the Item's handle. What does this handle resolve to? When passing along a collection AIP don't we also want to pass along all the Item AIPs as well? I'm think that the Item's handle doesn't get you an AIP package (METS document and all the Items bitstreams), but perhaps it does.
    - div@DMDID
      - I wish there was a way to use one value in this attribute instead of multiple. I imagine that's a pain to parse. There's the @GROUPID, but it's not an XML ID.

MODS Usage

Object's descriptive metadata crosswalked to MODS (or whatever the METS default is)

```
mods:mods
```
- ```
mods:mods/mods:name
```
  - @ID
    - Do our DSpace names have IDs? Can we use the mods:name@ID?
- ```
mods:mods/mods:extension/mods:dataAccessioned
```
  and
```
mods:mods/mods:extenstion/mods:dateAvailable
```
  - rather than extend the mods namespace by two custom elements, we should employ MODS available date extension point //mods:mods/mods:originInfo/mods:dateOther. mods:dateOther contains a type vocabulary where we could establish our definitions of accession and available dates. Here's the definition of the originInfo element set, I think all of our dates (accession, available, issued) fall well within the domain established by: Information about the origin of the resource, including place of origin or publication, publisher/originator, and dates associated with the resource. dateOther also allows the @encoding used with these dates. (SEE RW examples !!!!!!!!!!!!!!!)
- ```
mods:mods/mods:physicalDescription/mods:extent
```
  and
```
mods:mods/mods:physicalDescription/mods:internetMediaType
```
  - Shouldn't the mods:extent and mods.internetMediaType elements for each file be grouped under the same mods:physicalDescription
- Some elements that might warrant an @xml:lang
  - mods:abstract
  - mods:note
  - mods:subject
  - mods:titleInfo
  - mods:genre

PREMIS Usage

Here is what AIP Object (Item/Collection/Community) Technical Metadata (SourceMD) would look like as PREMIS. We should add PREMIS to AIP (not necessarily replacing the DIM formatted MD)

AIP Technical Metadata Example (DIM and PREMIS)

Here is what Bitstream Technical Metadata should look like (new elements added to PREMIS section)

Bistream Technical Metadata Example (DIM and PREMIS)