Need for evaluation date metadata

[mattgarrish]

Opening this issue since we touched on this in yesterday's telecon.

While this is important for the web, I'm not sure it's necessary for an epub publication. What would be the difference between the evaluation date and the last modified date?

Even if you republish without doing a re-evaluation, you can infer a renewal of the initial evaluation otherwise the certification should be removed. I expect users will do this, as it will be confusing understand why the dates might differ (e.g., does it mean it wasn't rechecked or that it continues to be valid to an old evaluation).

The only cases I can think of for an evaluation date would be: 1) a legacy record of when the publication was first evaluated (but this overlaps with revision histories which we don't address); and 2) if there were multiple evaluations and some aren't rechecked. Neither of these seems compelling enough to add the additional complexity of separate evaluation dates. But that's just my opinion...

[OriIdan]

I did not participate in the telecon, but I think I agree, there is no need for last modification date. This is something that is needed in a file system, it has no use in a publication.

…

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

On Fri, Mar 26, 2021 at 4:29 PM Matt Garrish ***@***.***> wrote: Opening this issue since we touched on this in yesterday's telecon. While this is important for the web, I'm not sure it's necessary for an epub publication. What would be the difference between the evaluation date and the last modified date? Even if you republish without doing a re-evaluation, you can infer a renewal of the initial evaluation otherwise the certification should be removed. I expect users will do this, as it will be confusing understand why the dates might differ (e.g., does it mean it wasn't rechecked or that it continues to be valid to an old evaluation). The only cases I can think of for an evaluation date would be: 1) a legacy record of when the publication was first released (but this overlaps with revision histories which we don't address); and 2) if there were multiple evaluations and some aren't rechecked. Neither of these seems compelling enough to add the additional complexity of separate dates. But that's just my opinion... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1590>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB43QDWY23NILRTLVJWXTTTFSD2XANCNFSM4Z3MW4IQ> .

[gregoriopellegrino]

From a third party certifier point of view I think it is useful to have the certification date, in particular if the EPUB creator changed the file without telling to the certifier.

This is to identify the right responsibilities in case of non-compliant content.

[mattgarrish]

This is to identify the right responsibilities in case of non-compliant content.

In a case like this, wouldn't you want to have an internal record that couldn't be tampered with by the publisher? A publisher might just update your date assuming everything is still good.

[mattgarrish]

Can this be addressed with existing metadata? For example:

<link rel="a11y:certifierReport" id="cert" href="http://example.com/report/abc">
<meta property="dcterms:issued" refines="#cert">2021-01-01</meta>

Since this metadata is evaluator-specific, it's always going to be weird if there isn't a report to link the date to. You'll have to do something like:

<meta property="a11y:certifiedBy" id="cert">Me</meta>
<meta property="dcterms:issued" refines="#cert">2021-01-01</meta>

But at least this way we don't propagate more date fields.

[gregoriopellegrino]

Fine for me!

[mattgarrish]

Let's close this issue off, then. If we find that the existing metadata isn't sufficient, at least we'll have a stronger basis for returning to this issue and figuring out what can be improved.

[iherman]

The issue was discussed in a meeting on 2021-09-09

• no resolutions were taken

View the transcript

3. Need for evaluation date metadata (pr epub-specs#1590)

See github pull request #1590.

Avneesh Singh: okay, so let's do that
… this one is about potentially having a certification date

Matt Garrish: if you want to put a date in your can use a dc:terms value, and to attach that to the certifier
… its not something we're defining, or that we require, but the question keeps coming up
… so this just adds an example to the spec

Avneesh Singh: any objections?

Charles LaPierre: and so you would use refines to point to the certifier?

Matt Garrish: yes

[gregoriopellegrino]

I am reopening this issue just for clarification. Here @mattgarrish suggests using dcterms:issued, while in the EXAMPLE 6 example there is dcterms:date.

Which of the two to use? Perhaps semantically dcterms:issued is better, but I don't have a strong opinion on that.

[mattgarrish]

Perhaps semantically dcterms:issued is better

I think I mentioned on a call that even though I proposed it here, it doesn't really work for a conformance statement. The definition is:

Date of formal issuance of the resource.

If we were dating the issuing of a certifier report, I'd agree this property is more appropriate. We don't issue the "conforms to" claim in the metadata; there's just a date when it was evaluated. That's what this field is modifying, as there isn't always a report that goes along with the claim.

That's why I suggested we should only use a regular date property.

[gregoriopellegrino]

Got it, thanks