AIP Details: METS, MODS, PREMIS Usage – Rob Wolfe's Comments
METS Usage
Code Block mets
element- code
@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 theCode Block mets@ID
. I would say theCode Block mets@ID
should be unique amongst all AIP documents, but the other IDs should just be unique within the document.
- @IDs should be used wherever available, I'll put a note about forming IDs in the profile spec.
mets/metsHdr
elementCode Block @createdate
andCode Block @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
- code
@OTHERMDTYPE
- We should require mets/dmdSec@OTHERMDTYPE if @MDTYPE = "OTHER"
Code Block mets/amdSec
– Item specific metadata encoded in DIMCode Block mets/amdSec/sourceMD
wasCode Block mets/amdSec/techMD
- Put Item/Collection/Community Technical Metadata into
Code Block sourceMD
section. Just replace parentCode Block techMD
element withCode Block sourceMD
(attributes remain the same) This technical metadata correctly falls under the usage of the sourceMD element. Code Block 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".
- "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?
- 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.
- Put Item/Collection/Community Technical Metadata into
Code Block 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.
Code Block mets/fileSec
Code Block mets/fileSec/fileGrp
- Did the "ORIGINAL" bundle get renamed "CONTENT"?code
mets/fileSec/fileGrp/file
- code
file@CREATED
andCode Block file@SIZE
- The DSpace SIP calls for the use of
Code Block @CREATED
for the file element, AIP examples do not useCode Block @CREATED
, but do useCode Block @SIZE
, which is not recommended by SIP.
- The DSpace SIP calls for the use of
mets/structMap
Code Block mets/structMap/div
Code Block 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 theCode Block FLocat
element which contains anCode Block @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.Code Block 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.
- 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.
MODS Usage
Object's descriptive metadata crosswalked to MODS (or whatever the METS default is)
Code Block mods:mods
- code
mods:mods/mods:name
Code Block @ID
- Do our DSpace names have IDs? Can we use the mods:name@ID?
Code Block mods:mods/mods:extension/mods:dataAccessioned
andCode Block 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
andCode Block 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)
Missing: Media:Bitstreamtechmd.xml.ogg
New METS Examples
I've edited the METS examples to incorporate some of the suggested changes.