Deep dive: Best practices for dates in Islandora MODS metadata

This document has drastically changed, as of 2021-11-05. A PDF copy of the previous version is available, if needed for reference. However, we strongly encourage the use of the current version going forward.

Please note: the standard MODS entry/editing form that comes by default with all LYRASIS-hosted Islandora instances does not support adding or editing the attribute values described below. If you are interested in bringing your dates into line with these best practices, contact us about enabling the Detailed MODS editing form.

Why did this document change?

Our primary concern in offering guidance on date metadata has shifted from MODS best practices, to positioning clients for a smooth migration to the new version of Islandora (more on that here).

The current Islandora stores all of your objects' descriptive metadata in MODS XML, which provides a lot of flexibility in how to record date values.

The new Islandora has a completely different model for storing your metadata. All values in date fields in the new version will need to be in valid EDTF encoding. New Islandora's support for EDTF is fairly comprehensive. Only the patterns expressing time-level (hour/minute/second) granularity are unsupported.

On one hand, the new version provides much less flexibility in how you may express dates. However, EDTF is an extremely expressive format, and limiting all dates to EDTF encoding fixes many long-standing complaints about how the current Islandora handles date sorting, faceting, and display. Many of these issues were directly related to the number of different date formats (w3cdtf, marc, iso8601, edtf, temper, and freeform/nonstandard values) supported by MODS, and the very flexible patterns available for recording dates in MODS.

The good news for you is that our recommendations for recording dates in the current Islandora have become much simpler.

Best practices

Encoding

As stated above, the new Islandora supports nearly the full EDTF standard.

Unfortunately, many of the EDTF date expressions would be unsuitable for display for end users in the current Islandora. Further, the current Islandora does not handle EDTF dates intelligently in sorting and faceting.

Therefore, we are recommending against recording EDTF encoded dates in your MODS.

Instead, LYRASIS has developed a temporary "pseudo-standard" date encoding guide that:

• supports user-friendly date display in the current Islandora
• provides acceptable (though not perfect) sort/facet behavior in the current Islandora
• maps directly and unambiguously to EDTF so that we will be able to transform the date data with confidence into what is expected by the new Islandora at migration time

We are calling this the LYRASIS EDTF-ready Date Format, and the detailed guide is available as an Excel or CSV file. As a bonus, this spreadsheet can be used as a concise reference to the EDTF standard.

IMPORTANT:
Opening the CSV directly in a spreadsheet application may mess up the date format examples. If using the CSV file, make sure the following columns get treated as Text when you open the file:

• Example pattern
• Example
• Islandora pattern

Interpreting/using LYRASIS EDTF-ready Date Format spreadsheet

Usage

In the spreadsheet, find the appropriate pattern for the date you need to express.

Record it in Islandora following the pattern in the "Islandora pattern" column.

Note: Where the "Islandora pattern" column is blank, you will see a "Do not use" instruction in the next column. We have not identified this pattern in existing client metadata, and it seems like use cases for the pattern are fairly unusual. If you need to use one of these, contact us and we will figure out how to express it.

Do not set the MODS encoding attribute.

Do not add additional MODS elements to express the date in another encoding.

Spreadsheet Columns
The columns "EDTF Level", "Section" and "Example" refer to and are taken directly from the EDTF standard documentation.

The "Example pattern" column is a non-specific, unique representation of each pattern that LYRASIS migration staff use internally.

The "EDTF notes/interpretation" column is mostly taken directly from EDTF, but in some cases clarifies the meaning of the pattern as we understand it.

The "Islandora pattern" column shows what you should record in your current Islandora date fields or MODS date elements.

The "Islandora notes" column provides usage guidelines/details.

The "edtf example order" column allows you to sort the examples in the order in which they appear in the EDTF standard.

The "Islandora sort order" column allows you to see how the "Islandora 7 pattern" values get sorted in I7 search results when ascending date sort is selected.

keyDate

When multiple dates are recorded, we strongly encourage labeling one of them (and only one of them!) with the keyDate attribute.

Islandora does not currently use this attribute to determine what date value should be used for sorting and faceting, but it should. We will use this attribute in the migration to the new Islandora to make sure the sort/facet date for each object is the one you expect.

 Examples:

Assign a keyDate when multiple dates are recorded:

No:

<dateCreated>1920 (approximate)</dateCreated>
<dateIssued>1972</dateIssued>

Yes:

<dateCreated keyDate="yes">1920 (approximate)</dateCreated>
<dateIssued >1972</dateIssued>

Assign keyDate to only one date value in a record:

No:

<dateCreated keyDate="yes">2000 (approximate)</dateCreated>
<dateIssued keyDate="yes">2010, 2011, 2013, and 2015</dateIssued>

Yes:

<dateCreated keyDate="yes">2000 (approximate)</dateCreated>
<dateIssued>2010, 2011, 2013, and 2015</dateIssued>

Note: It would be your choice whether you want this to sort under 2000 (dateCreated) or 2010 (dateIssued).

Point

In general, do not use.

Yes:

<dateCreated>2004 - 2006</dateCreated>

Use only if it is crucial that a date facet be populated with the start and end values.

Note that the entire date range will still not be accurately represented in a facet in current Islandora, so any faceting on range dates will have some confusing behavior. For example, in the first example below, the item would come up in the facet value for 2004 and 2006, but not if you clicked on the facet value for 2005

Only if necessary:

Start and end dates will populate date facet:

<dateCreated>2004 - 2006</dateCreated>
<dateCreated point="start">2004</dateCreated>
<dateCreated point="end">2006</dateCreated>

Never:

<dateCreated point="start">2004</dateCreated>
<dateCreated point="end">2006</dateCreated>

Note: for dateIssued elements, only the first-occurring value is displayed. It is on the roadmap to display only non-point dateCreated values, unless there are only dateCreated values with point. In the latter case, a range will be constructed via the pattern "{start value} - {end value}". The other MODS date elements are used less frequently by our clients and are currently all displayed.

Qualifier

Do not use.

Sorting

Current behavior:

If any dateIssued elements are present, the value of the first-occurring dateIssued is used as the date_sort value.

In the absence of dateIssued values, the value of the first-occurring dateCreated element is used as the date_sort value.

In the absense of either dateIssued or dateCreated, the value of the first-occurring dateOther element is used as the date_sort value.

The current logic does not check for valid date formats, so some strange search result sorting can be explained by "approximately 1992" sorting before "circa 1800" because "a" sorts before "c".

The LYRASIS EDTF-ready date format spreadsheet can be sorted on the "Islandora sort order" column to see how the date patterns it suggests get sorted in the current Islandora.

Faceting

Any MODS date element can be specified as a facet for filtering search results.

The important thing to note here is that you can have a "Date Created" facet and a separate "Date Issued" facet. But there cannot currently be a "Date" facet that combines values from the two different elements.

The labels of facets are easy to change, so you could display the facets as "Creation" and "Publication" or however you wanted to label them.

Note that only values recognized as valid date types by Solr will be included in facets. Range dates and approximate dates as typically recorded for display are not valid date types in Solr, so will not be included in facets, hence some of the apparently redundant data entry recommended above.

There are special options for date facets that include a graphical date slider and type-in date range filtering. Example:

If you would like any date facets configured for your Islandora instance, contact us at Zendesk support.