How do you use 'date' metadata?

[Chris Clawson]

My project is a mostly a historic repository of images from my home area. In some cases, we know the exact date a picture was taken. In the worst case, a date would only be a guess made from a historian ("circa 1895").

Of course, many other date related fields are defined. There are international standards and guidelines issued from Google and others.

We wish to identify and curate everything added. How shall we deal with imperfect information, and keep compatible with established guidelines? In DSpace, where, when and how are the 'date' metadata fields important in this case?

[Bram Luyten]

Hi Chris,

not a full answer, but hopefully this helps:

example item: http://demo.dspace.org/xmlui/handle/10673/43?show=full

dc.date.accessioned and dc.date.available are set by DSpace automatically, at the point when the item exits the workflow and becomes a "live"/archived item in the repository. Wouldn't recommend to fill them out manually or to edit them.

Features like RSS feeds, Recently submitted items on the frontpage and possibly also OAI rely on the contents of these dates.

dc.date.issued is the most commonly used field for a "publication" date. For content that doesn't exist elsewhere, dc.date.issued can coincide with dc.date.available. But very often, the date of publication in another medium, website, or journal is used there.

The submission form user interface date format allows:

YYYY

YYYY-MM

YYYY-MM-DD

But I'm pretty sure (not tested though!) that if you would fill it out with a timestamp, like 2018-01-07T08:55:55Z, it would work as well.

You generally don't want to fill it out with "circa YYYY", or "195X"

The main areas that you are risking to break are the Browse by Issue Date pages, cfr http://demo.dspace.org/xmlui/browse?type=dateissued

Or you may have items not showing up in your Discovery date facets. (see screenshot)

If you want to describe historical coverage of the images, I would recommend to store this information as text, in the dc.coverage.temporal field or dcterms.coverage.

cfr https://wiki.lyrasis.org/display/DSDOC6x/Metadata+and+Bitstream+Format+Registries

with kindest regards,

Bram

Bram Luyten 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Gaston Geenslaan 14, 3001 Leuven, Belgium DSpace Express Hosting - Open Repository Hosting - Custom DSpace Services

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/2599252f-fa1b-40fe-b8e5-56ceb4d3df15o%40googlegroups.com.

[Mark H. Wood]

On Mon, Jun 29, 2020 at 02:27:37PM +0200, Bram Luyten wrote:
...
> *dc.date.issued *is the most commonly used field for a "publication" date.

> For content that doesn't exist elsewhere, dc.date.issued can coincide with
> dc.date.available. But very often, the date of publication in another
> medium, website, or journal is used there.
> The submission form user interface date format allows:
> YYYY
> YYYY-MM
> YYYY-MM-DD
>
> But I'm pretty sure (not tested though!) that if you would fill it out with
> a timestamp, like 2018-01-07T08:55:55Z, it would work as well.
>
> You generally don't want to fill it out with "circa YYYY", or "195X"
>
> The main areas that you are risking to break are the Browse by Issue Date
> pages, cfr http://demo.dspace.org/xmlui/browse?type=dateissued
> Or you may have items not showing up in your Discovery date facets. (see
> screenshot)

Allow me to underscore the fact that, in this field, there are not
just established guidelines to consider; this field will be
interpreted by software and must use a syntax that is recognized by
the software if you want to avoid unfortunate and mysterious behavior.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[David Bigwood]

Chris,

It sounds like you want to use something like the Extended Date Time Format, https://www.loc.gov/standards/datetime/ It can handle uncertain dates, date ranges, when only the decade is known and more. However, I don't think any of the date fields in DSpace are set-up to handle it correctly. If I'm wrong I hope someone lets me and everyone know. Maybe you could use a field not as a means to sort or filter by date but more as a text for display information purposes? Part of the summary field perhaps?

David Bigwood

dbig...@lpi.usra.edu

Lunar and Planetary Institute

Library, Planetary Image Facility

[emilio lorenzo]

Hi

for a historic repository  we manage an extended list of dates as in http://liburutegibiltegi.bizkaia.eus/browse?type=dateissued    .  Library & archives managers needed some more (or maybe less) ¿precision?  when describing the dates. The original records in the catalogues showed some very special dates:

[c.1488] ,   1901-19-?]  ,   1494/1495,  (1217?-1274),   [ca. 1515-1517]

The order of items in browse -by-date seems to behave quite well   (i.e 1480-1562   before 1492...etc)
 

Also, the DC schema was extended to deal some additional characteristics (see 139 & 128 in this list-->
 
    11    dc.date.accessioned    Date DSpace takes possession of item.
    12    dc.date.available    Date or date range item became available to the public.
    13    dc.date.copyright    Date of copyright.
    14    dc.date.created    Date of creation or manufacture of intellectual content if different from date.issued.
    139    dc.date.description   
    15    dc.date.issued    Date of publication or distribution.
    16    dc.date.submitted    Recommend for theses/dissertations.
    128    dc.date.updated    The last time the item was updated via the SWORD interface
    10    dc.date    Use qualified form if possible.

best

Emilio

[Mark H. Wood]

On Tue, Jun 30, 2020 at 07:45:13AM -0700, David Bigwood wrote:
> It sounds like you want to use something like the Extended Date Time
> Format, https://www.loc.gov/standards/datetime/ It can handle uncertain
> dates, date ranges, when only the decade is known and more. However, I
> don't think any of the date fields in DSpace are set-up to handle it
> correctly. If I'm wrong I hope someone lets me and everyone know. Maybe you
> could use a field not as a means to sort or filter by date but more as a
> text for display information purposes? Part of the summary field perhaps?

Executive summary: as always with time, this is a large, complex and
tangled problem. DSpace doesn't fully address it.

There are two related issues with imprecise dates:

o how do we store them?
o how do we compare them?

DSpace stores all metadata in character form. Things like dates are
interpreted when used.

DSpace is able to parse incomplete dates such as "1957" in some
fields, but IIRC it treats them as instants, not imprecise dates or
ranges. Answering the question, "is 'circa 1850' within the interval
'1851' to '14-Feb-1907'," is an *interesting programming problem*.

We have an interest in imprecise dates here, so I began to explore
storing them as DCMI Period
(https://www.dublincore.org/specifications/dublin-core/dcmi-period/),
a couple of years ago, but I don't have anything resembling working
code to, for example, *search* in such fields. (To do that
efficiently would require writing a new datatype for Solr, among other
things.)

EDTF looks interesting, since it distinguishes between imprecision and
uncertainty. Thanks for the link.