Page History
...
Metadata Field | Value | ||
|---|---|---|---|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="921c15c79e482e12-cf209388-48a24f87-95708f17-129e2b0c3fe5d117b362b352"><ac:plain-text-body><![CDATA[ | dc.identifier.uri | Handle of Site (format: | ]]></ac:plain-text-body></ac:structured-macro> |
dc.title | Name of Site (from dspace.cfg 'dspace.name' config) |
...
Metadata Field | Value |
|---|---|
dc.title | Bitstream's name/title |
dc.title.alternative | Bitstream's source (getSource()) |
dc.description | Bitstream's description (getDescription()) |
dc.format | Bitstream Format Description (getUserFormatDescription()) |
dc.format.medium | Short Name of Format (getFormat().getShortDescription()) |
dc.format.mimetype | MIMEType of Format (getFormat().getMIMEType()) |
dc.format.supportlevel | System Support Level for Format (getFormat().getSupportLevel()) necessary to recreate Format during restore, if the format isn't know to DSpace by default) |
dc.format.internal | Whether Format is internal (getFormat().isInternal()) |
...
necessary to recreate Format during restore, if the format isn't know to DSpace by default) |
- Outstanding Question: Why are we recording the file format support status? That's a DSpace property, rather than an Item property. Do DSpace instances 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 an 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
...
Metadata Field | Value | ||
|---|---|---|---|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6d61692556deb8de-458b8f46-4b4741bd-baa79f36-3fbcf2708f744dd85d638458"><ac:plain-text-body><![CDATA[ | dc.identifier.uri | Site Handle (format: | ]]></ac:plain-text-body></ac:structured-macro> |
...
Overview
Content Tools