Allow multiple instances of dcterms:modified

[mattgarrish]

I think it's a pity only one dcterms:modified META is allowed. Allowing multiple dcterms:modified META elements would allow the preservation inside a package of the history of changes and even provide the user with it if necessary.

(Submitted by Daniel Glazman)

[murata2makoto]

How do you construct Release Identifiers? By using the latest modification time?

[mattgarrish]

Either the reading system will have to calculate which is the latest or we'd need requirements like the latest modified time must be listed first and reading systems must use the first one encountered.

I suggest we defer, as I'm sure there are better ways we could do revision histories. A date alone isn't going to be all that meaningful to a user.

[TzviyaSiegman]

I agree with @mattgarrish

[laudrain]

I don't think it is the place and time to manage revision history.
Yes let's defer.

[mattgarrish]

Since we've acknowledged that the release identifier hasn't worked out as expected, there's not a strong case to keep restricting dcterms:modified to a single instance.

This would also match the dc guidance.

We may want to define the first in dom order as the last modification date, though, so it's not open to interpretation.

[OriIdan]

But what about release identifier? I think we still need such identifier.

…

-- Ori Idan CEO Helicon Books http://www.heliconbooks.com

On Wed, Mar 3, 2021 at 6:44 PM Matt Garrish ***@***.***> wrote: Since we've acknowledged that the release identifier hasn't worked out as expected, there's not a strong case to keep restricting dcterms:modified to a single instance. This would also match the dc guidance <https://www.dublincore.org/resources/userguide/creating_metadata/#Modified> . We may want to define the first in dom order as the last modification date, though, so it's not open to interpretation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB43QH7JF4SCN3TQP6DL43TBZRNPANCNFSM4COGUOVA> .

[iherman]

The issue was discussed in a meeting on 2021-03-04

List of resolutions:

• Resolution No. 2: Close issue 841, will not change usage of dcterms:modified

View the transcript

2. Allow multiple instances of dcterms:modified

See github issue #841.

Wendy Reid: I believe the initial intent was to allow this to show progression of update to book

Matt Garrish: yeah, a revision history
… at the time we cared because of Release Identifier
… but now it doesn't seem to matter as much
… but if we have multiple, we should define which one is the last modified

Brady Duga: I also don't really care, but what does this enable?
… you can't add comments to these fields, so it would just be a bunch of ambiguous dates and times
… not against removing restriction on only having one, but also not really any features that would benefit from doing so

Wendy Reid: in practice, one thing that I've seen publishers do is track the version of the epub on the copyright page

Dave Cramer: all the big trade publishers do that
… ours is a long string that is unintelligible to outsiders
… and we'd keep doing this regardless of changes to this field

Proposed resolution: Close issue 841, will not change usage of dcterms:modified (Wendy Reid)

Brady Duga: +1

Matthew Chan: +1

Masakazu Kitahara: +1

Matt Garrish: 0

Wendy Reid: +1

Toshiaki Koike: +1

Marisa DeMeglio: 0

Wendy Reid: mgarrish please feel free to refine the language

Resolution #2: Close issue 841, will not change usage of dcterms:modified

[iherman]

@mattgarrish, @wareid it was not clear to me from the minutes if there is an editorial change to do on this based on the discussion, so I did not close the issue. If there is no change to do, one of you can close it I guess...

[mattgarrish]

No, there was just a general comment from @wareid that if I see anything in the section that could be improved to feel free to fix. I think it's fine as-is for having only one value.