dc:coverage refinement?

10 posts / 0 new
Last post

Hi all,

I am trying to figure out how to properly set refinements for the dc:coverage element...

The specification tells it should look like: DC.coverage.spatial / DC.coverage.temporal. This is for meta elements in html/xhtml but I don't know how to apply it in content.opf file properly.

<dc:coverage.spatial> ??

Any information more than welcome!


You need to use the meta tag, I expect:

<meta property="dc:coverage.spatial">...</meta>

EPUB only allows core DCMES elements, so you can't create an element with a refinement on it, but you have more flexibility in the meta property attribute. You just have to switch the "DC." html prefixing mechanism with the "dc:" prefix for epub.

You'll also need to declare the dc prefix on the root package element to avoid validation errors, like this:

<package ... prefix="dc: http://purl.org/dc/terms/">


EPUB 3 even has a predefined prefix for Dublin Core Terms 'dcterms', different from the namespace and prefix for Dublin Core Elements and the usage of the term 'modified'
is required for each book, respectively for each OPF-file.
Usually the prefix 'dc' is used for the elements, namespace 'http://purl.org/dc/elements/1.1/'.
As an educated guess, not all programs looking at the OPF-file have a proper implementation for namespaces and prefix definitions, therefore one might already avoid confusion, if one does not use the prefix 'dc' for the terms. because 'dcterms' is already predefined.

The usage for other terms however can be simply aligned to the usage of 'modified'.
Because Dublin Core already defines the meaning of each term, there is not necessarily a need
to use it only as a refinement for the older elements, they can be used as a replacement.

Here for example:
<meta property="dcterms:spatial">Hannover</meta>
<meta property="dcterms:temporal">2000/2014</meta>

This is obviously correct, ok to use in an EPUB 3 OPF-file, but one cannot assume, that any
viewer cares about metadata in EPUB archives anyway, therefore always better to duplicate
all metadata into an XHTML-file, added as normal content document to the book to ensure, that readers have simple access to this information.

Something like 'coverage.spatial' has no meaning in the namespace http://purl.org/dc/terms/ .

By the way, there is a funny problem here, the EPUB Publications 3.0.1 notes, that 'Reserved prefixes should not be overridden in the prefix attribute', but defines the reserved prefixes in another document noting: 'This document is subject to change at any time.'
Therefore authors using now the prefix attribute to define a prefix cannot be sure, that their
prefix will be reserved later for the EPUB vocabulary, resulting finally in an invalid book.
Just one more inconsistency with metadata in EPUB/OPF - surely not the best and most respected part of the format ;o)
Already for one predefined 3.0.1 prefix there is already trouble:
'rendition' http://www.idpf.org/vocab/rendition/#
Effectively, if one wants to use it and one ones to validate the book, one has to define it with the
prefix attribute anyway, because the version number is still 3.0 an there is no such predefined prefix - finally the idea of predefined prefixes mainly causes problems, it is not well-thought-out .

Thanks! Very helpful! I am happy I am not the only one who consider the whole thing being a bit inconsistent (and very coder unfriendly) :)

It doesn't matter where the prefixes are defined, since the scenario you suggest can happen even if they're defined in the spec itself. Moving them outside the spec means not waiting years between revisions to add needed prefixes.

And nowhere does it say that a document will become invalid if you've already declared a prefix before it gets standardized. The only way a document becomes invalid is by contradicting a "must". Not following the "should" only results in a warning you that you're using a reserved prefix, but it doesn't register as an error. There's an argument that some vendors might be so strict as to reject even warnings, but that's not a problem the specification can solve. We can't write a specification that is so totally rigid there are either errors or nothing.

And recommending, or using, dcterms is at your own peril. There is a predefined prefix since it's needed for expressing dcterms:modified, but dcterms metadata is for the world of linked metadata.

The spatial property has a range of Location and temporal PeriodOfTime, not literal text, so you're suggesting invalid use. That's why I offered using the DC values, as you won't run afoul of the linked data nature that Dublin Core has defined for most of the dcterms properties. You need to take a look at the DC folks expect these properties to be used:


Without being able to nest metadata, exactly how are you going to create these classes? The inherent complexity of DCTERMS is part of why EPUB didn't migrate away from the DCMES elements. We could have switched from elements to the properties in the elements namespace, but that wouldn't achieve anything since the elements are needed for EPUB 2 compatibility, anyway.

And that we have the elements doesn't mean you can't use meta expressions of them if there's a case. I hadn't realized there might possibly be one, until I saw this post.

Unfortunately some references to fragment identifiers at http://purl.org/dc/terms/ seem not to work, but one can guess/interpolate here.

For 'spatial' it is noted, that one has to use the range/class 'Location', this notes: 'A spatial region or named place.' It does not indicate, how to identify such region or place.
In my example 'Hannover' or 'Hannover, Deutschland' is a method to identify a region.
For 'temporal' it is noted, that one has to use the range/class 'PeriodOfTime'.
This is defined to be 'An interval of time that is named or defined by its start and end dates.'
In my example '2000/2014' indicates this, not very precise, but this is not required, there are no
details on how to note such a period exactly, the string fits to ISO 8601, this is what one might expect for general usage.
Therefore I cannot see a problem here with this examples.
Because there is no precise definition of allowed content, programs anyway cannot do much more as to extract either more sub-elements or strings.

About the problem with prefixes - well if there is exactly one set of prefixes for one version of EPUB, referenced by this version, it is ok. Currently the version indication 3.0 is used both for version 3.0 and 3.0.1 with different predefined prefixes, therefore this causes definition trouble,
that could have been avoided either without predefinitions, with proper version indication or with prefix lists for each version.
'should' and 'must' - ok, as an author I typically follow a recommendation, if it explicitly notes to avoid some issues if possible, but if you propose, one can simply ignore this as an author, you are of course right ;o)

Use on own risk - will, this is always true, but if the syntax is correct, there is not much risk, that a proper parser will fail due to unknown things, noted in a correct and defined way.
As already mentioned, one just cannot expect to see an effect due to this or other metadata and some other features possible in EPUB archives. And there is not much, authors can do about this...

Ok, thanks to both of you! However, this is too much abstract to me. Could you use it in a couple of examples, please? :o)

Thanks again, it is not easy to figure out how to use basic vocabularies together. I guess the right record would be then:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"

And then I could use basic <dc:coverage>Place OR Time</dc:coverage>


<meta property="dcterms:spatial">Ppace</meta>
<meta property="dcterms:temporal">Time</meta>

Or to simply combine then together, right? If so, it helped me to solve much more questions at once! Very nice tip!

You do not need to define the namespace with xmlns:dcterms="http://purl.org/dc/terms/",
this would be only necessary, if you use the terms directly as elements like those with the dc prefix for Dublin Core elements - possible in XML documents and maybe allowed in EPUB2, but for
EPUB 3 the usage of metadata from other resources is restricted to the Dublin Core elements and the usage of the meta element with a property, here with prefix and element name.
Because for this meta element construction the prefix dcterms is already predefined, there is
no need to define it, for other one may need it, can be done for example in the package element with the attribute prefix, for example for EPUB 3.0:
prefix="dnb: http://www.dnb.de/
rendition: http://www.idpf.org/vocab/rendition/#"

Later, within metadata one may write:
<dc:contributor id="wilhelm">Wilhelm Busch</dc:contributor>
<meta refines="#wilhelm" property="dnb:gnd">http://d-nb.info/gnd/118517880</meta>

<meta property="rendition:flow">scrolled-doc</meta>

<meta property="dcterms:modified">2014-12-21T13:28:07Z</meta>
<meta property="dcterms:created">1869</meta>

<meta property="dcterms:spatial">Wiedensahl, Deutschland</meta>
<meta property="dcterms:spatial">Mechtshausen, Deutschland</meta>
<meta property="dcterms:temporal">1832/1908</meta>

Well, the last three entries are not very good examples here, this would be information related to the book without refinement, here the data are indeed about the author of the book,
for such a use case it would be better to write

<meta refines="#wilhelm" property="dcterms:spatial">Wiedensahl, Deutschland</meta>
<meta refines="#wilhelm" property="dcterms:spatial">Mechtshausen, Deutschland</meta>
<meta refines="#wilhelm" property="dcterms:temporal">1832/1908</meta>

Still this is not optimal, because it is not obvious, how Wiedensahl and Mechtshausen are related to Wilhelm Busch - who was born in Wiedensahl and died in Mechtshausen, to
provide such data about persons, one should use other vocabularies, not Dublin Core,
what is mainly about works, not persons, therefore just an example for general refinement,
not really a recommendation to use this to refine information about the author, for this the
refinement dnb:gnd is already the better example included, it references an identifier for the
person. I do not have much ideas on spatial or temporal metadata to create good examples,
spatial might contain coordinates as well ;o)

Note even more, that dcterms:temporal is a period of time, not just a time.
If you need more precision than just the year, you can maybe extend it in the usual way:
<meta property="dcterms:temporal">1832-04-15/1908-01-09</meta>
Or if your books is about only a few days or hours, maybe:
<meta property="dcterms:temporal">2015-02-16T17:13:11Z/2015-02-17T19:54:17Z</meta>
or another option with date and length (2 hours):
<meta property="dcterms:temporal">2015-02-16T18:43:37PT2H</meta>

Whohoo! Thank you! Great inspiration for next thinking/learning!

Secondary menu