Date metadata for legacy content

2 posts / 0 new
Last post

Hi from France!

Within EPUB 2, metadata DATE was not clearly defined as to which date was to be recorded, and so wasn't Dublin Core. This situation had the advantage that it could be defined by those creating the EPUB and its metadata. So did the University of Chicago, who specifically stated that metadata related to the source materials should be recorded, and not to its digital surrogate.
http://memory.loc.gov/ammem/award99/icuhtml/dcguide.html

We at the BnF are digitizing printed books and want to make them available as EPUB, but for us, the relevant date is, as for the University of Chicago, the one related to the source materials.

Now, EPUB 3, on the other hand, is quite clear on this point:
"The date element must only be used to define the publication date of the EPUB Publication."
http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-opf-dcmes-...

Yet, there is this statement:
"Additional dates should be expressed using the specialized date properties available in the [DCTERMS] vocabulary, or similar."
But Dublin Core does not provide much more either; aside the DATE element, there are "dateAccepted", "dateCopyrighted" and "dateSubmitted" which are useless to describe an original document being digitized
http://dublincore.org/documents/dcmi-terms/

Let's put it this way: creator and title metadata are "inherited" from the original document, they are the same in both paper and EPUB versions. But, this is not the case for "date" and "publisher" metadata.

For instance, "Les liaisons dangereuses" printed originally 1782, Amsterdam, Paris: Durand, 1782
has been reedited several times, e.g.
Paris: Dentu, 1891
Paris: Bibliothèque des Curieux, 1913

All of them may be digitized and edited as an EPUB, all of them would be (re)edited by the BnF in 2013.
We find it important to record and inform the reader that the relevant date is 1782 (or 1891 or 1913) and not 2013. But we find little room for the description of the legacy (paper) document with EPUB metadata.

We would like to hear comments and opinions of other institutions which may have encountered the same situation, specially (but not only) those undergoing digitization programs. We also estimate this issue may be of interest not only to institutions doing legacy digitization, but also to (commercial) publishers digitizing ancient, out-of-copyright titles.

J-P Moreux, Nicolas Rucks

A quick note that the dcterms vocabulary has more dates than just the three you listed. Look for properties that refine the date type, not for the presence of "date" in the name.

In that light, why can't you use one or more dcterms:issued properties to reflect the original issue date and/or any of the subsequent reissues?

It seems like if you're giving no meaning to the date you insert, it will be of no value to the reading system or the reader, since there is no way to process or convey it (i.e., why would a reading system display a generic date, and what label would it give to the date?).

The dcterms properties reflect what the opf:event attribute on the dc:date element in EPUB 2 was designed to handle, and one of the goals of the EPUB 3 revision was to do away with the custom attributes. OPF 2 defined the date as the "[d]ate of publication", so the meaning of the element hasn't technically changed across specifications, only a limitation to one instance imposed now that opf:event is gone.

Secondary menu