Web App Manifest vs Web Publication Manifest

With the on-going development of a specification for a Web App Manifest and its implementation in various browsers, it is legitimate to ask what makes a publication different from an application.

Metadata

The current version of the Web App Manifest has a number of metadata elements:

• name
• short_name
• lang
• description

In comparaison, a publication has much richer metadata, for example the current draft for EPUB 3.1 has the following elements:

• identifier
• title
• modified
• language
• contributor
• creator
• date
• subject
• type

Publications can also cover a vast number of subjects: metadata for comics will be very different from metadata for a journal for example. External vocabularies and an extension model that allows their use provide the ability to express this information, no matter what the publication is about.

Also, while apps are treated as separate entities, publications are often aggregated together in reading applications, where the user can organize them and filter them based on rich metadata.

While applications require a limited set of metadata to be presented properly, publications have much stronger requirements: they require a much larger set of default metadata and an extension model that allows external vocabularies.

For additional details and example, it's worth taking a look at the metadata associated to the default context. The Web Publication Manifest has also three extension mechanisms for metadata: 1) both schema.org and bib.schema.org can be used for additional metadata, 2) it's possible to define new contexts and 3) the manifest can contain elements from any external vocabulary, if they're expressed as a URI.

Navigating a Publication vs an App

The current version of the Web App Manifest has a single entry point to the application: its homepage, identified by the start_url element. All navigation has to happen through that first resource, either through links or various interactions in JS.

On the other hand, in a publication the "entry point" doesn't matter that much, instead a number of things are used for the purpose of navigation:

• a collection of resources in reading order (associated to the spine element in both EPUB and the Web Publication Manifest draft)
• one or more table of contents
• various other collections that can be useful for navigation (list of illustrations, alternate reading orders, a dictionary or glossary with references to resources in the publication)

In addition, a resource in a publication may be part of more than one publication, which is one of the reason why links (no matter if they're in the HTTP headers, the head or the body of an HTML resource) are not sufficient for navigating a publication.

Navigation must also be expressed in a document that is easy to identify (through a rel value or a specific media-type) and accessible, which is why expressing that info in JS is unsuitable for a publication.

While applications can rely strictly on an entry point and hypermedia links for navigation, publications require a number of collections (at least a list of resources in reading order) to provide proper navigation.

Nature of the Resources

A Web Application is primarily created using HTML/JS/CSS resources.

For a publication, that's not necessarily the case. For example an audiobook is a type of publication that can have exclusively audio files in addition to a manifest. Same principle for comics, where bitmap images are the most important resources.

A publication doesn't necessarily need to be primarily HTML based. Specific types of publications can rely entirely on images or audio files.