publication_date: support for EDTF lvl 0

[ppanero]

Currently only publication_date is specified to support EDTF.

However, all the rest of fields have date-time as format. Should they only be of format date? date was only introduced in JSONSchema draft 7 (more info here).

Redefinition of this task ;)

As a depositor, I may be unsure about the publication_date of a record (e.g. sometime in World War II), but I want to convey this range as the publication date, because a publication date is needed to mint a DOI (DataCite) and it is more informative than nothing.

technical implications
Allow publication_date field to be an EDTF of lvl 0

• marhsmallow
• jsonschema
• elasticsearch + create a lower end date for sorting purposes

[saragon02]

Curious about other team members' proposed use cases for time in the date-time format. The only case I envision is if someone cataloging or depositing materials needs timestamp information on metadata that they edited within the same day. If a new record version is created on the same day, versioning information serves for differentiation.

[tmorrell]

I don't think publication_date should have time. Time is useful for meta-metadata fields like the system created and updated dates that you might use for scripting. But this shouldn't be something we expect from the users.

[lnielsen]

Reopening this based on a discussion in the chatroom. Could we support EDTF format for publication date?

• EDTF Spec

Specifically, it would be only "Level 0" of the spec for dates:
Example 1: 1985-04-12
Example 2: 1985-04
Example 3: 1985

Internal schema

publication_date: User-provided date according to Level 0 of EDTF.
_publication_date_sort: Expansion of publication_date into a date e.g.:

1985 -> 1985-01-01
1985-04 -> 1985-04-01

Above is what Biodiversity Literature Repository in Zenodo has been doing with dates.

[lnielsen]

python-edtf might come in handy :-)

[lnielsen]

Summary of further discussions

EDTF Level 0 includes time interval as well, so we can support time interval with dates (not time):

• 1939/1945
• 1939-09/1945
• 1939-09-01/1945

Marshmallow

We would need Marshmallow fields in order to parse and validate EDTF dates. Ought to be relatively simple with the Python library.

Deposit form

We will need a practical approach for the input field widget in the deposit form. Something like:

• Default to a date selection widget that allow only a date selection. For EDTF syntax the user will have to manually enter it into the text field.

Templates/rendering

Rendering an EDTF date is a bit more tricky due to L10N. Python EDTF can deliver earliest/latest date as well as a time struct object. Babel requires a full Python date object in order to localise it. Babel further defines four formats (full, long, medium, short) or a custom format. We could define further formats for EDTF:

>>> format_date(date=date(1939,9,1), format='long')
u'September 1, 1939'
>>> format_date(date=date(1939,9,1), format='MMMM, y')
u'September, 1939'

This would mean we should likely add a format_edtf() function to Invenio-I18N plus a Jinja filter. In the REST API we likely need a formatted date as well to avoid that the JS frontend needs to implement the EDTF formatting as well.