Metadata

Via new JSON-LD contexts
Via properties defined by full URIs
Implementation: currently unknown metadata are lost. To make them available would let users of the SDK (i.e. apps, e.g. education) to get them easily without modifying the SDK.
Example: Calibre metadata -> https://readium.org/readium-css/docs/CSS21-epub_compat.html#metadata
An "otherMetadata" array will contain items with property name + value, extracted from the EPUB meta element.

Collections

Expressed as new roles.
If part of our extensions, they are in registries
If not they are full URIs.
An "otherCollections" array will contain items with a role + subCollection.

Links

Extensibility for properties, should be similar to metadata
children and alternate should be part of the core model, not generic extension point

https://github.com/readium/architecture/blob/master/streamer/parser/metadata.md

https://github.com/readium/webpub-manifest/tree/master/schema

See description of the problem here:
readium/webpub-manifest#26 (comment)

Hi there! We have been employing the EPUB parser Type definition in our project and it's been a splendid experience so far! However, we've come across a scenario that piqued our curiosity and hoped to gain some insight into the underlying decisions.

In our use case, we've come across multiple instances where certain elements from the Encryption XML and OPF could potentially be optional. Our expectation was that the type check would indicate this to us, but it appears that these elements are always expected to have a value as per the parser's definition. For instance, it's our understanding that the title, language, and identifier are Required elements in publication metadata, while others could be optional, and similarly, the Keyinfo from the encryption format could be optional as well.

While we do perform our own type checks, there are times when we rely on the parser's type definition as a source of truth, which has led to some discrepancies. Any insights into this would be greatly appreciated. Thank you!

https://github.com/evidentpoint/r2-webpub-model-js/

https://github.com/readium/webpub-manifest/blob/master/schema/metadata.schema.json#L140

CHECK:

https://github.com/readium/webpub-manifest/blob/ffb350ca09c85d5f15cb4ae0453bd0b3dcb15440/schema/metadata.schema.json#L81-L119

I see that you can get the version from the OPF, but that requires passing in a zip. We are currently using r2-shared-js and already have the publicationParser working (it works great! So thanks for that!). But we would like to be able to tell if it's an EPUB 2 or EPUB 3 or higher, just from the publicationParser.

Here is an excerpt of what we are doing:

        const pub = await publicationParser.PublicationParsePromise(path);

        if (typeof pub.Metadata.Title === "string") {
            bookTitle = pub.Metadata.Title;
            coverUrl = pub.GetCover()?.Href || '';
            manifest = serializable.TaJsonSerialize(pub);

            const zipInternal = pub.findFromInternal("zip");
            if (!zipInternal) {
                throw new Error("There is no publication zip!");
            }

It would be nice if we could check, for instance. pub.Version and be able to tell the EPUB version. Is there another way to do this?

Thanks!
Jonah

For example:
https://github.com/IDPF/epub3-samples/blob/master/30/wasteland/EPUB/wasteland.opf

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" unique-identifier="uid" xml:lang="en-US" prefix="cc: http://creativecommons.org/ns#">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="uid">code.google.com.epub-samples.wasteland-basic</dc:identifier>
        <dc:title>The Waste Land</dc:title>
        <dc:creator>T.S. Eliot</dc:creator>
        <dc:language>en-US</dc:language>
        <dc:date>2011-09-01</dc:date>
        <meta property="dcterms:modified">2012-01-18T12:47:00Z</meta>
        <!-- rights expressions for the work as a whole -->
        <dc:rights>This work is shared with the public using the Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.</dc:rights>        
        <link rel="cc:license" href="http://creativecommons.org/licenses/by-sa/3.0/"/>
        <meta property="cc:attributionURL">http://code.google.com/p/epub-samples/</meta>
        <!-- rights expression for the cover image -->       
        <link rel="cc:license" refines="#cover" href="http://creativecommons.org/licenses/by-sa/3.0/" />
        <link rel="cc:attributionURL" refines="#cover" href="http://en.wikipedia.org/wiki/Simon_Fieldhouse" />        
        <!-- cover meta element included for 2.0 reading system compatibility: -->
        <meta name="cover" content="cover"/>
    </metadata> 
    <manifest>
        <item id="t1" href="wasteland-content.xhtml" media-type="application/xhtml+xml" />
        <item id="nav" href="wasteland-nav.xhtml" properties="nav" media-type="application/xhtml+xml" />
        <item id="cover" href="wasteland-cover.jpg" media-type="image/jpeg" properties="cover-image" />
        <item id="css" href="wasteland.css" media-type="text/css" />
        <item id="css-night" href="wasteland-night.css" media-type="text/css" />
        <!-- ncx included for 2.0 reading system compatibility: -->
        <item id="ncx" href="wasteland.ncx" media-type="application/x-dtbncx+xml" />
    </manifest>
    <spine toc="ncx">
        <itemref idref="t1" />        
    </spine>    
</package>

EDIT: see comment below #16 (comment)

Note how <meta property="cc:attributionURL">http://code.google.com/p/epub-samples/</meta> is missing in the ReadiumWebPubManifest:
http://readium2.herokuapp.com/pub/L2FwcC9taXNjL2VwdWJzL3dhc3RlbGFuZC1vdGYtb2JmLmVwdWI%3D/manifest.json/show/all
(or https://readium2.now.sh/pub/L2hvbWUvbm93dXNlci9zcmMvbWlzYy9lcHVicy93YXN0ZWxhbmQtb3RmLW9iZi5lcHVi/manifest.json/show/all )

{
    "@context": "https://readium.org/webpub-manifest/context.jsonld",
    "metadata": {
        "@type": "http://schema.org/Book",
        "title": "The Waste Land",
        "identifier": "code.google.com.epub-samples.wasteland-otf-obfuscated",
        "author": "T.S. Eliot",
        "language": "en-US",
        "modified": "2019-04-24T16:58:39.677Z",
        "published": "2011-09-01T00:00:00.000Z",
        "description": "OTF font obfuscated using algorithm defined in OCF 3.0, fallback to sans-serif system font",
        "rights": "This work is shared with the public using the Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license."
    }
}

See: readium/webpub-manifest#66 (comment)

This code should be disabled (this will trigger the AdditionalJSON property and dc:source will be preserved "as is"):

This code remains:

See:
readium/architecture#111

Also see:
https://github.com/readium/r2-streamer-swift/blob/630d8953cbad98fb229233caa9d98b2ce16474b3/r2-streamer-swift/Parser/EPUB/EPUBMetadataParser.swift#L206-L243

Same issue as readium/r2-streamer-js#44

My use case here is to batch process EPUB publication files from within the NPM package.json scripting mechanism.

Example:

{
  "name": "rwpm-batch-convert",
  "version": "1.0.0",
  "description": "Convert publications to include Readium Web Publication Manifest files.",
  "main": "index.js",
  "scripts": {
    "test": "r2-shared-js-cli [some input here]"
  },
  "author": "Juan Corona <[email protected]>",
  "license": "MIT",
  "dependencies": {
    "r2-shared-js": "^1.0.13"
  }
}

...also make sure that parsed values (e.g. from XML source) are filtered as per the allowed enumerated values. Avoid boilerplate code by automating the "enum" checks (which is not a native Javascript type, just a TypeScript constructs that transpiles to plain string definitions)

https://github.com/readium/webpub-manifest/blob/ffb350ca09c85d5f15cb4ae0453bd0b3dcb15440/schema/metadata.schema.json#L136

https://github.com/readium/webpub-manifest/blob/ffb350ca09c85d5f15cb4ae0453bd0b3dcb15440/schema/metadata.schema.json#L33

This commit introduced a postinstall command. That command depends on rimraf which is listed as a devDependency. This causes an install failure when attempting to install this package without the devDependencies which would be traditional in a production build.

https://github.com/standardebooks/oscar-wilde_an-ideal-husband/blob/4a454ad572188d210ea2d26c4004033694b0ec3c/src/epub/content.opf#L19-L28

http://readium2.herokuapp.com/pub/aHR0cHM6Ly9zdGFuZGFyZGVib29rcy5vcmcvZWJvb2tzL29zY2FyLXdpbGRlL2FuLWlkZWFsLWh1c2JhbmQvZG93bmxvYWRzL29zY2FyLXdpbGRlX2FuLWlkZWFsLWh1c2JhbmRfYWR2YW5jZWQuZXB1Yg%3D%3D/manifest.json/show/all

CC @jccr @HadrienGardeur

This issue is similar to spine vs. readingOrder.

In publication metadata, direction should be renamed to readingProgression:

JSON Schema:
https://github.com/readium/webpub-manifest/blob/d0b5694e662faf88262a3dc6a50ca32220fc825a/schema/metadata.schema.json#L120
( https://github.com/readium/webpub-manifest/blob/master/schema/metadata.schema.json#L120 )

Existing client implementations that parse the JSON property name directly (rather than using the in-memory data model) will need to update their code to support both the legacy direction term, as well as readingProgression (as we did when switching from spine to readingOrder).

See:
https://github.com/readium/architecture/blob/master/streamer/parser/metadata.md#identifier

Related issue:
https://github.com/readium/r2-streamer-swift/issues/113