revision metadata

[GoogleCodeExporter]

I think we should add revision metadata to the metadata specification.

Original issue reported on code.google.com by ori@helicontech.co.il on 19 Mar 2013 at 6:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ori, 
can you clarify what meta fields you believe are needed?

Original comment by markus.g...@gmail.com on 12 Apr 2013 at 5:39

[GoogleCodeExporter]

Is there a reason why the DCMES elements relating to this aren't sufficient? 
E.g., dc:isVersionOf, dc:hasVersion, dc:isReplacedBy, dc:replaces, 
dc:isRequiredBy, dc:requires, dc:isFormatOf, dc:hasFormat, etc.?

Original comment by bkasd...@apexcovantage.com on 12 Apr 2013 at 5:47

[GoogleCodeExporter]

Note, too, if revision here means version numbers the working group decided
against this after a lengthy debate in the last revision.

There were many producers who felt that our including a version property
would a) conflict with their own internal versioning, and b) be meaningless
unless we defined the versioning scheme, and we could find no consensus on
a scheme.

Original comment by mgarrish on 12 Apr 2013 at 6:01

[GoogleCodeExporter]

Why don't simply add a <meta property="version>xx.xx</meta>
So every author can use his own versioning algorithm?

Original comment by ori@helicontech.co.il on 12 Apr 2013 at 7:01

[GoogleCodeExporter]

The package identifier (the combination of the unique identifier with the
dcterms:modified date) represents an implicit version number already. It's
incremental and sortable, and standardized, but reflects time instead of an
incrmenting number.

If the version is only for internal identification purposes, you can create
a prefix to do the same without codifying a new property in the
specification:

<package prefix="my: http://example.com">
...
<meta property="my:version">1.0</meta>

Having an epub-defined property may be simpler, but it comes at the expense
of clouding the identification mechanism that already exists, as far as I
can tell.

Original comment by mgarrish on 12 Apr 2013 at 8:27

[GoogleCodeExporter]

I definitely do NOT think we should mess with the identification mechanism of 
the EPUB. I thought the original question was about providing descriptive 
information about the version of the _document_ (e.g., the book), not the EPUB. 
That's why I suggested the use of DCMES, which has a vocabulary for those 
purposes. Having said that, though, it should be pointed out that this would be 
pretty much purely _informational_ ("this book is a revision of such-and-such a 
book" or "this document replaces that document") but not _interoperable_.

Original comment by bkasd...@apexcovantage.com on 12 Apr 2013 at 10:17

[GoogleCodeExporter]

I agree, we should not mess with the identification mechanism.
I think the dcterms are not clear enough for simply static the version of an 
EPUB file.
I meant the version of the EPUB not necessarily the document since I think that 
the document version will probably be encoded in the ISBN number etc.

Original comment by ori@helicontech.co.il on 13 Apr 2013 at 5:25

[GoogleCodeExporter]

Should we close this ticket as potentially conflicting with existing metadata, 
then?

If not, could you propose the property(-ies) needed, Ori, in a way that will 
avoid any ambiguity with the package identifier?

Original comment by mgarrish on 15 Apr 2013 at 5:08

[GoogleCodeExporter]

I suggest the property "version"
So we can have a meta element such as <meta property="version">1.0</meta>

Original comment by ori@helicontech.co.il on 15 Apr 2013 at 5:42

[GoogleCodeExporter]

Ori, unless you can describe how your proposal differs from the existing 
versioning mechanism in EPUB 3 (see [1]), we will not be taking action on this 
issue. 

[1] 
http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-opf-metadata-ident
ifiers-pid

Original comment by markus.g...@gmail.com on 2 Jul 2013 at 9:05

[GoogleCodeExporter]

I don't think that a timestamp as given in the EPUB3 versioning mechanisem is a 
version number.
What I propose is a version number just like a software has version 1.0 1.1 1.2 
etc.
The timestamp is just the build time and has nothing to do with version.
We may not need a complicated mechanism of major and minor number, maybe just 
one number.

Original comment by ori@helicontech.co.il on 3 Jul 2013 at 2:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This issue is a rehash of the content-version debate from 3.0. For context for 
Ori:

A "content-version" property issue was originally slated for 3.0, but we had to 
define what value it could take if it was to be usable by reading systems and 
in distribution channels:
https://code.google.com/p/epub-revision/issues/detail?id=52

No consensus was ever found on that scheme, and the property was ultimately 
dropped and the issue closed because the package identifier, with its temporal 
component, could serve both uniqueness and identification, finding the middle 
ground of what producers needed:

https://code.google.com/p/epub-revision/wiki/Telcon20110126#Publication_Identity
https://code.google.com/p/epub-revision/wiki/Telcon20110126Minutes

(We even considered keeping the property around as a "do-what-you-want" 
placeholder, as I recall, but there were objections to that not only for the 
general confusion factor with the package identifier, but because an epub 
"version" number would conflict with interal versioning that publishers were 
already using. I can't remember anymore who raised that objection, though.)

But, sure, the package identifier is not a "version" number in the software 
sense, but it solved the distribution and reading system requirements for 
comparing and sorting versions of an epub in a consistent and easily understood 
way. (What are the criteria for major/mid/minor revisions of an ebook, anyway, 
which the accepted proposal got us away from?)

We have the package identifier for machine processing of epubs, and the edition 
title type for human consumption of the content.

See my comment at #6 for how you can create your own internal versioning number 
that's perfectly valid to include in an EPUB and carries no meaning outside of 
your own production if that's all you're looking for.

Giving EPUB a second version property that carries no specific meaning but 
gives the appearance of being a requirement to include is problematic, at best. 
It would make for strange spec prose that introduces a property only to 
indicate its irrelevance for processing.

Original comment by mgarrish on 3 Jul 2013 at 6:57

[GoogleCodeExporter]

Just confirming, as Metadata Subgroup Lead, that Matt's comment is 100% correct 
in describing why we came out where we did. Publishers needed an identifier 
that could persist across minor corrections to what they considered "the same 
publication" (the publication identifier, the form of which is left up to the 
publisher) and systems needed to unambiguously detect when two files of the 
same publication were different in any way, and which of them was the more 
recent (hence the timestamp, which Matt refers to as the "temporal component"). 
The combination of the two serves as a unique package identifier.

He is also correct in remembering that there was serious objection to mandating 
a software-like versioning requirement; the reason he may not remember who 
raised that objection is that many publishers objected. There was clear 
consensus in the group that publishers had to be free to make their own 
decisions about what characterizes a new version, a new edition, an _alternate_ 
version (which is not the same as a new version which supplants the previous 
one), etc. This is even more true now that we are seeing publishers of 
publications other than books embracing EPUB. Versioning of publications does 
not always follow a linear replacement model.

--Bill K

Original comment by bkasd...@apexcovantage.com on 3 Jul 2013 at 7:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

On the September 5 301 WG concall it was resolved to close this issue without 
action. The metadata extensibility mechanism can be used for this purpose. 

https://docs.google.com/document/d/1_O81TZ62H8IaxL00quOAX7uc1ROoJWmmVoDAJaRhl7A/
edit#

Original comment by markus.g...@gmail.com on 19 Sep 2013 at 8:18

• Changed state: WontFix