Open danielweck opened 4 years ago
Consider that json has no notion of namespace (big difference with XML) BUT json-ld re-introduces this notion via @context and @prefix.
The dcterms
prefix is defined by json-ld (https://www.w3.org/TR/json-ld11/#conformance) and dcterms:conformsTo
is a different property than conformsTo
in the "https://www.w3.org/ns/pub-context" context.
Therefore we must be able to process conformsTo
in W3C web publications (unique), and should also be able to process and map to RWPM dcterms:conformsTo
(unique).
Note that other dcterms
properties can be present in W3C and Readium WP, essentially dcterms:description
(unique string; could evolve to a localized string) and dcterms:subject
(array of strings).
Also, the new "Daisy, Schema.org accessibilty metadata" highlights the use of accessibilitySummary for expressing "This publication conforms to WCAG 2.0 Level AA.".
Should we really also support dcterms:conformsTo
or is it a deprecated recommendation from older guidelines? processing accessibility metadata should not become a nightmare.
accessibilitySummary is human readable, and possibly multilingual. dcterms:conformsTo is machine readable.
in EPUB3, dcterms:conformsTo is a metadata link with property attribute (akin to rel) in EPUB2 it is a classic meta name+value pair. in W3C ... I’m not sure, to be honest.
in any case, I think that conformsTo does not necessarily occur only once, for example a publication may declare compliance with triple-A WCAG as well as other standards. the r2-shared-is model stores an array of values (URls) for that purpose.
So we just need to figure out whether the W3C’s conformsTo construct (which is defined as dcterms as well) also supports the accessibility semantics in addition to the “audiobook” etc. URI which seems to be its primary purpose in the specification.
Related issue: https://github.com/readium/webpub-manifest/issues/65
there is no collision per-se, but the dcterms:conformsTo metadata is also used in the accessibility standard, so the R2 model will preserve an array of authored values (from EPUB, LPF, etc.)
Consequently, a parser must check all given values when looking for the audiobook URI in the LPF publication.json manifest. the wording in the mapping documentation should be improved to reflect this.
https://github.com/readium/architecture/blob/master/other/W3C/audiobooks.md
http://kb.daisy.org/publishing/docs/metadata/evaluation.html
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/conformsTo
related originating issue:
https://github.com/readium/readium-desktop/issues/1023#issuecomment-620641563