ONIX Certified By

[gregoriopellegrino]

From EditEUR's feedback:

Certified By

Value: Textual Data from metadata
This technique relates to Certified By principle.
Not available in ONIX
New code for list 196 – value 93

[clapierre]

@gregoriopellegrino What about CertifierCredential ?

[gregoriopellegrino]

In my opinion there is no equivalent for CertifierCredential, I would use code list 196, code 98 Trusted Intermediary contact.

[GeorgeKerscher]

The semantics seem to be completely different.

[clapierre]

I agree @GeorgeKerscher Trusted Intermediary contact is defined as "carries the e-mail address for a contact at a ‘trusted intermediary’, to whom detailed questions about accessibility for this product may be directed"

Its somewhat related but it is defined as an email address, where our CertifierCredential is either a Name, or a URL link to a web page, which may have a mailTo link eventually.

Eg: for GCA we have the following URL.
<meta property="a11y:certifierCredential”>https://bornaccessible.org/certification/gca-credential/

[mattgarrish]

I don't think ONIX can support credentials as the code list values aren't themselves structured. Even in EPUB it's a bit flaky, as there's an assumption the content is only certified by one party so the credential has to apply to that certifier. The two bits of information aren't strongly related, which would require using the refines attribute (and even that is always a bit hacky).

[clapierre]

@mattgarrish I didn't think we ever talked about having more than one certifier, the EPUB metadata property is singular "certifierCredential". I know AccessModes & AccessModeSufficient has has multiple values which will be very hard with ONIX I would imagine, but this shouldn't be an issue as I would think the certifierCredential would be for one organization/entity.

[mattgarrish]

Metadata properties are usually singular in naming (feature, hazard, etc.). You repeat the property for each instance.

Credential has a cardinality setting of zero or more in its definition table, so it is allowed to repeat in EPUB.

But what we never got into was requiring credentials to be explicitly associated with one certifier. Technically, the way the metadata works in EPUB, we're saying the publication has a certifier credential. I suspect we opted to live with this ambiguity because refines was supposed to be removed/deprecated in EPUB 3.1 when we were creating the specification.

We may want to reconsider not having explicit associations, but given the time that has expired it might be better just to live with what we did and change the cardinality to zero or one. It might be worth exploring again what happened to the schema.org credential property, too.

My concern, however, is that it's not a good thing to propagate our mini-mess over to ONIX, so unless ONIX can structure the certifiedby field to incorporate the credential, I'm not sure it will be a good thing to add.

[mattgarrish]

And as some memories drift out of the haze, didn't we allow more than one certifier because there was the chance multiple people might work on the assessment and all be listed rather than a single organization? I believe that's what led to this note:

If an EPUB Publication is certified by an organization, users will typically want to know the name of that organization. Including the name of the individual(s) who carried out the assessment, instead of the name of the certifying organization, is generally discouraged, as it can diminish the trust the user has in the claim.

It seems doubtful someone would certify their content twice with different people/organizations, but I suppose there's always the issue of whether re-certification of an update might lead to multiple entries.

[TzviyaSiegman]

it is not exactly the same, but note that https://schema.org/hasCredential exists. This is from the Badging community, and I believe is used by IMS. It is also being considered for use by the Verifiable Credentials Education Task Force for use for things like diplomas. Should we consider an attempt to make it more robust?

[mattgarrish]

Ya, hard to say without an example. In any case, epub couldn't support a structured value so we'd still have to reduce it to a text value like certifierCredential:

<meta id="cert" property="a11y:certifiedBy">Acme Certifying Co.</meta>
<meta property="schema:hasCredential" refines="#cert">someA11yCredential</meta>

It might be a case where we just have to live with what we have for epub given its limitations and instead look at alternatives for formats with better metadata frameworks, like audiobooks, so we don't get stuck with unstructured metadata.

[avneeshsingh]

For current revision of documents we can incorporate code list 196, code 93 for certified by.
We can incorporate ONIX equivalent of CertifierCredential when it will be available.
Regarding schema.org credentials, it is used more like a qualification in education etc. It is not fit for our purpose in the current state. However we can explore how we can influence the improvements for our use.