🙋 Click here to create a DAMS service request
Note |
---|
Work in Progress |
Expand | ||
---|---|---|
| ||
|
Excerpt | ||||||||
---|---|---|---|---|---|---|---|---|
MODS Element name: <originInfo><dateCreated keyDate="yes"> (Creation date) or <originInfo><dateIssued keyDate="yes"> (Issuance date) Short definition: System-generated, machine-readable date value derived from either Creation Date or Issuance Date. Input guidelines: The system will create a machine-readable date element with a keyDate attribute based on the user-provided information for Date created or Date issued. If a date range is specified, only the start date will be used as key date. If textual date information is provided, the key date will be a numerical date approximating the textual date information. The machine-readable date is for instance used for sorting of search results.
|
System-generated, machine-readable date value derived from either Creation Date or Issuance Date.
System-generated metadata element. These elements cannot be edited in the DAMS metadata web form.
http://www.loc.gov/standards/mods/userguide/origininfo.html
<originInfo> is a container element that contains all subelements related to publication and origination information. It includes all dates associated with the creation, issuance, and/or publication of the resource. Dates associated with the temporal content of the resource go under <subject>, and dates associated with the metadata go in <recordInfo>. Data is input only within each subelement.
Currently no attributes for originInfo are implemented in the DAMS.
The following subelements of <originInfo> are used in the DAMS:
The system will create a machine-readable date element with a keyDate attribute based on the user-provided information for Date created or Date issued. If a date range is specified, only the start date will be used as key date. If textual date information is provided, the key date will be a numerical date approximating the textual date information. The machine-readable date is for instance used for sorting of search results.
Note |
---|
The ingest process currently ignores a keyDate attribute set by users when preparing metadata as MODS XML. Instead, the system will create a new machine-readable date element with a keyDate attribute based on dateIssued or dateCreated (in this order and depending on which of the two is available). Any user-provided keyDate attribute will be stripped from the metadata upon ingest. If you want to designate a specific date element as the key date in metadata prepared for batch ingest, add the following attribute-value pair to the respective element: keyGen="yes". |
Attribute name | Details | XPath syntax examples | |||||
---|---|---|---|---|---|---|---|
point | value:
| originInfo/dateCreated[@keyDate="yes" and @point="start"] | |||||
keyDate | value:
| originInfo/dateCreated[@keyDate="yes"] | |||||
encoding | value:
| originInfo/dateCreated[@keyDate="yes" and @encoding="w3cdtf"] |
No subelements for dateCreated.
The system will create a machine-readable date element with a keyDate attribute based on the user-provided information for Date created or Date issued. If a date range is specified, only the start date will be used as key date. If textual date information is provided, the key date will be a numerical date approximating the textual date information. The machine-readable date is for instance used for sorting of search results.
Note |
---|
The ingest process currently ignores a keyDate attribute set by users when preparing metadata as MODS XML. Instead, the system will create a new machine-readable date element with a keyDate attribute based on dateIssued or dateCreated (in this order and depending on which of the two is available). Any user-provided keyDate attribute will be stripped from the metadata upon ingest. If you want to designate a specific date element as the key date in metadata prepared for batch ingest, add the following attribute-value pair to the respective element: keyGen="yes". |
Attribute name | Details | XPath syntax examples | |||||
---|---|---|---|---|---|---|---|
point | value:
| originInfo/dateIssued[@keyDate="yes" and @point="start"] | |||||
keyDate | value:
|
| originInfo/dateIssued[@keyDate="yes"] | ||
encoding | value:
| originInfo/dateCreated[@keyDate="yes" and @encoding="w3cdtf"] |
No subelements for dateIssued.
Code Block | ||||
---|---|---|---|---|
| ||||
<originInfo> <dateCreated keyDate="yes" encoding="w3cdtf" point="start">2001-01-01</dateCreated> </originInfo> |
Depending on the direction of mapping necessary, check
...
Dublin Core field | Mapping condition | MODS element | Notes |
---|---|---|---|
dc:date | MODS to DC | dateCreated[@keyDate="yes"] | The date value in the MODS element is prefixed with the text "Created: ". |
dc:date | MODS to DC | dateIssued[@keyDate="yes"] | The date value in the MODS element is prefixed with the text "Issued: ". |
see http://www.loc.gov/standards/mods/mods-mapping.html#publication. The following specific guidelines apply for the DAMS:
MARC 21 field | Mapping condition | MODS element | Notes |
---|---|---|---|
* | MARC to MODS | dateCreated[@keyDate="yes"] | Do not map MARC data into MODS element with attribute keyDate. |
* | MARC to MODS | dateIssued[@keyDate="yes"] | Do not map MARC data into MODS element with attribute keyDate. |
In general, all MODS metadata is imported into the DAMS Solr server upon ingest. The ingest process generates Solr fields typically named according to the following schema:
...