Adding information about the profile in the manifest

[mickael-menu]

Currently, RWPM doesn't contain any information about its profile (e.g. Audiobook, DiViNa...), but we need this information for example to figure out which Navigator to use.

At the moment, we're using different heuristics per profiles:

• Audiobook: has http://schema.org/Audiobook for its @type property, or contains only resources with an audio type in its reading order.
• DiViNa: contains only resources with a bitmap type in its reading order.
• LCPDF: contains only resources with a PDF type in its reading order.

This can be source of errors, and it would be useful to have the profile indicated in the manifest itself instead. Any thoughts on how it could look like? A conformsTo property, for example.

[HadrienGardeur]

I believe that using conformsTo is the right approach.

One could imagine for example publishing a collected edition of a podcast using our audiobook profile, in which case:

{
  "@context": "http://readium.org/webpub-manifest/context.jsonld",
  
  "metadata": {
    "@type": "https://schema.org/PodcastSeries",
    "conformsTo": "https://readium.org/webpub-manifest/profiles/audiobook"
    "identifier": "http://example.com/podcast",
    "title": "Publishing Podcast: Collected Edition"
  }
}

[danielweck]

Please also see: readium/architecture#134

[llemeurfr]

In this case, we'll need to manage a small registry of profiles. If we consider https://readium.org/webpub-manifest/#8-extensibility plus the pdf we also need to handle, we'll define:

• https://readium.org/webpub-manifest/profiles/epub
• https://readium.org/webpub-manifest/profiles/audiobook
• https://readium.org/webpub-manifest/profiles/divina
• https://readium.org/webpub-manifest/profiles/pdf

re. epub, shouldn't it be ebook instead? it would be on the same plan as audiobook and digital visual narrative, and a W3C Web Publication or a Daisy 2.02 publication would all end-up as a RWPM with this profile.

[HadrienGardeur]

There's already a registry of profiles available at https://readium.org/webpub-manifest/profiles/

[llemeurfr]

This is the pointer to the specification of conformsTo in the W3C Publication Manifest:
https://www.w3.org/TR/pub-manifest/#profile-conformance

(defined as a string or list, with the note 'The conformsTo property can also be used to indicate conformance to other specifications and standards (e.g., to [wcag21]).'

[mickael-menu]

Is this settled?

In the navigator, should we by default not inject any JavaScript nor Readium CSS in Readium Web Publications, unless the manifest contains this?

{
  "metadata": {
    "conformsTo": "https://readium.org/webpub-manifest/profiles/epub"
  }
}

[mickael-menu]

I implemented it in Swift in readium/swift-toolkit#19

I also added a Publication helper conforms(to:) which uses the conformsTo metadata as a hint but also checks the content of the reading order to make sure the conformance is valid.

/// Returns whether this manifest conforms to the given Readium Web Publication Profile.
public func conforms(to profile: Publication.Profile) -> Bool {
    guard !readingOrder.isEmpty else {
        return false
    }

    switch profile {
    case .audiobook:
        return readingOrder.allAreAudio
    case .divina:
        return readingOrder.allAreBitmap
    case .epub:
        // EPUB needs to be explicitly indicated in `conformsTo`, otherwise
        // it could be a regular Web Publication.
        return readingOrder.allAreHTML && metadata.conformsTo.contains(.epub)
    case .pdf:
        return readingOrder.all(matchMediaType: .pdf)
    default:
        break
    }

    // Fallback for extension profiles.
    return metadata.conformsTo.contains(profile)
}

Apps are encouraged to switch to this to check if a Publication can be opened with a given Navigator. For example publication.conforms(to: .epub).