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/dmdSec
@OTHERMDTYPE
mets/amdSec
– Item specific metadata encoded in DIM
mets/amdSec/sourceMD
was mets/amdSec/techMD
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
mets/amdSec/digprovMD
mets/amdSec
Bitstream specific metadata encoded in PREMIS and DIM
mets/fileSec
mets/fileSec/fileGrp
mets/fileSec/fileGrp/file
file@CREATED
and file@SIZE
@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
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
Object's descriptive metadata crosswalked to MODS (or whatever the METS default is)
mods:mods
mods:mods/mods:name
@ID
mods:mods/mods:extension/mods:dataAccessioned
and mods:mods/mods:extenstion/mods:dateAvailable
mods:mods/mods:physicalDescription/mods:extent
and mods:mods/mods:physicalDescription/mods:internetMediaType
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)|^AIP-ITEMPREMIS.xml|||\AipPrototype RWComments
Here is what Bitstream Technical Metadata should look like (new elements added to PREMIS section)
Bistream Technical Metadata Example (DIM and PREMIS)|^Bitstreamtechmd.xml|||\
I've edited the METS examples to incorporate some of the suggested changes.
Item METS AIP|^AIP-I442rwedit.xml||^AIP-I442rwedit.xml\