Abstract

This PRISM Source Vocabulary Specification describes the HTML5-based markup to exchange article content; includes normative material.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at https://www.w3.org/TR/.

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

1    Status

This document represents the IDEAlliance PRISM Source Vocabulary Overview Specification

The location of this document is:

psv-spec.html

2    Introduction

Because nextPub participants firmly believe that the Source is the Solution, the Working Group has developed the PRISM Source Vocabulary (PSV) Specification.  PSV is a standard framework for encoding digital content and configuring content management (CM) and DAM systems to create and produce future-ready content.

The PSV Specification is made up of a set of four documents.  This document, the PRISM Source Vocabulary (PSV) Specification [PSVS], provides the technical, detailed specification for the PRISM Source Vocabulary.

The nextPub model is based on digital capture and management of all content and associated rich media.  Source content is semantically rich enough to enable the publisher to select content and automate layout and delivery to a wide variety of publishing platforms in platform-native formats.  This model, based on the new PRISM Source Vocabulary (PSV) Specifications, has been designed to support today’s issue-based publications as well as to enable publishers to aggregate content in new ways to create new digital content channels that extend beyond the traditional publication models.

PRISM Source Vocabulary (PSV) Specification defines a framework and building blocks designed to enable the implementation of the nextPub Publishing Model.  The PSV framework is intentionally flexible set of building blocks that each publisher can deploy according to their specific publishing strategy and business model.

Figure 1.1 The PSV Framework

The PSV Specification defines robust metadata elements and controlled vocabularies that can be used to configure federated source content / rich media repositories.  Metadata fields and values used in this specification are drawn from the IDEAlliance PRISM 3.0 Metadata and Controlled Vocabulary Specifications.  By way of future-proofing, nextPub recommends encoding content using HTML5 tagging enhanced with PRISM-based class semantics.

Dublin Core, PRISM, PRISM Usage Rights, PRISM Recipe Metadata and other relevant PRISM metadata namespaces along with elements from the new psv: namespace are used to construct the PSV Framework.  XML structures unique to this specification for content encoding are given the namespace psv:

The recommended namespace for PSV markup is:
xmlns:psv=”http://prismstandard.org/namespaces/psv/1.0/”

Note: There is no official schema for HTML5.  However, nextPub has developed a schema for the PRISM Source Vocabulary Specification for the purpose of illustrating PSV structures in this specification.  For content encoding, the PSV schema is specifically designed to be more restrictive than a true HTML5 schema would be in order to make source content encoding and transformations to delivery channel formats much more straightforward. The design goal was to define a valid HTML5 subset for the content encoding portion of PSV.

In this Specification, the recommended HTML5-based PSV XML model is illustrated using model diagrams produced with the XML Spy software product.  These diagrams show the PSV element and attribute structure.  The legend for reading XML model diagrams is shown in Figure 1.2.  Elements that are required by the model are shown in a solid box.  Elements that are optional are shown in a dotted box.  Likewise attributes may be required (solid box) or optional (dotted box).  A repeatable occurrence of elements is indicated by numbers below each element box to the right. 

The diagrams also indicate how elements are assembled. When building some models, elements may occur in a sequence with a specified order.  Other models provide a choice from among a number of elements.  The legend in Figure 1.2 shows the connectors for sequence and choice.

Figure 1.2 The Legend for XML Diagrams

T The PRISM Documentation Package has been reorganized and some specifications renamed to more accurately reflect the nature of each specification module.  The PRISM documentation package includes the following specifications and documents:

This document provides compliance specification.

This is the set of documents that outline the prism metadata fields and values by PRISM metadata category.  PRISM has modularized its metadata specification by namepace so users may pick those modules that meet their unique business requirements without having to implement the entire PRISM specification.

This module documents the PRISM Markup Elements and Attributes for use with the PRISM Aggregator Message (PAM) and other aggregator messages.     This set of documents includes:

This module documents the PRISM Inline Markup Elements and Attributes for use with the PRISM Aggregator Message.  This set of documents includes:

These modules are new with PRISM 3.0.  All controlled vocabularies and their terms are documented in this publication set. 

       The Guide to the PRISM Aggregator Message [PAMGUIDE] documents the PRISM Aggregator Message (PAM), an XML-based application of PRISM.

       The Guide to the PRISM Aggregator Message for Web Content [PAMWGUIDE] documents the PRISM Aggregator Message (PAM), an XML-based application of PRISM.

       Guide to the PSV Aggregator/Distributor Message Package [PAMPGUIDE] documents how to use the PRISM metadata fields and pamP XML messaging tags to deliver content to content aggregators/distributors.  The Guide documents the pamP XML message structure and provides the pamP XSD and document samples.

       The Guide to PRISM Contract Management [CONTRACTSGUIDE] documents an XML-based PRISM contract management model.  The Guide is accompanied by an XSD that can be used as the basis for developing a contract management system that interfaces with the PRISM Rights Summary to populate ODRL policy statements. Reference [ODRLRSGUIDE]

       The Guide to PRISM Metadata for Images [IMAGEGUIDE] documents an XML-based PRISM Profile 1 application for the expression of the structure and use of PRISM Metadata for Images and can be used as the basis for developing an image management system based on PRISM Metadata for Images and for implementing PMI in XML.

       The Guide to PRISM Recipe Metadata and XML Encoding [RECIPEGUIDE] documents the XML-based recipe model for developing a recipe database, for tagging a wide variety of recipes in XML and for tagging recipes within a PAM Message.

       The Guide to PRISM Usage Rights [RIGHTSGUIDE] documents an XML-based PRISM application for the expression of PRISM Usage Rights.  The Guide is accompanied by an XSD that can be used as the basis for developing a digital rights management system based on PRISM Usage Rights.

       PAM to PSV_Guide [PAMPSVGUIDE] documents mappings from PAM XML to PSV XML.

In 2010, Idealliance developed a series of specifications collectively known as the PRISM Source Vocabulary.  The use case for PSV is to encode semantically rich content for transformation and delivery to any platform. This Specification is made up of a modular documentation package that builds on PRISM 3.0 and HTML5.  Over time new modules may be added to the documentation package.  The documentation package for PSV, PRISM Source Vocabulary Specification Version 1.0 consists of:

While PRISM is primarily a metadata specification, it also includes some XML schemas that define encoding of specific kinds of content for publication and interchange.  The PRISM schemas include:

       Contracts_xsd.zip contains a schema that can be used to encode publication contracts.

       Crafts_xsd.zip contains a schema that can be used to encode crafts.

       Image_xsd.zip contains a schema that can be used to encode images.

       PAM_xsd.zip contains a schema that can be used to encode a PRISM aggregator message.

       pamW_xsd.zip contains a schema that can be used to encode a PRISM aggregator message for Web content.

       pamP_xsd.zip contains a schema that can be used to encode a PRISM aggregator/distributor message package.

       PSV_xsd.zip contains a schema that can be used to encode content in PRISM Source Vocabulary.

       Recipe_xsd.zip contains a schema that can be used to encode recipes.

       Rights_xsd.zip contains a schema that can be used to encode usage rights.

PRISM has defined 38 controlled vocabularies using PRISM controlled vocabulary markup.  See The PRISM Controlled Vocabulary Specification [PRISMCVS].  All CVs are available in CVs.zip.

PRISM namespace declarations can be found in Namespaces.zip.  The following are the recommended Namespaces for PRISM metadata:

PSV Content Management Schema

In order to assist implementers develop a PSV-based federated content management solution, the nextPub Working Group is providing an XML Schema (XSD) that can serve as the basis for the design of a PSV content repository. 

Note: The PSV CM schema is not designed for tagging content.  It is provided simply to serve as a basis for the design of a content repository.  Metadata building blocks from this schema can be combined with HTML5 by publishers who wish to develop a hybrid PSV metadata and content tagging schema.

Because PSV is a flexible framework, it supports many different use case scenarios.  A different schema, using the PSV metadata fields and content encoding can be developed for each different use case.  In order to assist PSV implementers, the nextPub Working Group is planning to provide a number of XML Schemas (XSDs) to support common use cases including tagging an article and transmitting articles to content aggregators.

The following terms and phrases are used throughout this document in the sense listed below. Readers will most likely not fully understand these definitions without also reading through the specification.

3    PRISM Source Vocabulary Framework

This section provides an overview of nextPub PRISM Source Vocabulary Framework.  PSV Specification defines robust metadata elements and controlled vocabularies that can be used to configure federated source content / rich media repositories.  Metadata fields and values used in this specification are drawn from the IDEAlliance PRISM 3.0 Metadata and Controlled Vocabulary Specifications.  By way of future-proofing, nextPub recommends encoding content using HTML5 tagging enhanced with PRISM-based class semantics.

The specification for the PRISM Source Vocabulary does not use the PRISM/PAM XML message structure. The PRISM Source Vocabulary is made up of a metadata block designed to configure a CM/DAM (<psv:metadata) as well as an HTML5-compliant <head and <body for encoding content.  See Figure 3.1.

Figure 3.1 The PRISM Source Vocabulary XML Structure

Note:  If you need to transform PSV into HTML5 to deliver for browser display, you may wish to transform some of the metadata in the <psv:metadata block into <meta tags in the HTML5 head.  A PSV to HTML5 Transformation Guide to document the transformation of PSV XML into HTML5 for delivery to browsers is planned to be added to the PSV Documentation Set in the future.

This section provides summary of PSV metadata block.  This block was designed to enable the management and aggregatation of units of content for any purpose; from creating an issue of a magazine, to creating a bookazine or even to new collection types in the future.  See Figure 3.2.

Figure 3.2 PSV Metadata Structure

Only two metadata fields are required by PSV.  The first is the specification of content type and the second is a unique identifier for that content.  All other metadata fields are optional and will be determined by a publisher based on their business strategy and requirements.

That said, PSV metadata must be semantically rich enough to enable publishers to manage and assemble content for any purpose on any platform.  The metadata delivered to any device will be only that metadata that is critical to navigating articles assembled as a “publication” for delivery.

When establishing a nextPub PSV repository, a unit-of-storage must be specified.  Currently magazine publishers are capturing source content at the article level.  This is because, to date, the dominant use case was the delivery of content to content aggregators on an article-by-article basis.  New use cases underlying the nextPub effort do nothing to change the assumption that the basic unit of storage and access is at the article level of a magazine.  However, for other publication types such as books or blogs, other units of storage are indicated.

Note:  While magazines are currently delivering articles combined with a cover, contents and ad materials to a tablet or other digital device, use cases foreshadow the day when we might want combine articles, not based on issue, but by topic or some other unifying metadata.  Hence we have retained the “generic article” as the basic unit of XML content management so this goal might be achieved.

It is important to understand that when we say an article is the basic unit of content storage, we are referring to a generic article rather than a physical article of a magazine.    In the early days of PRISM, it could be assumed the unit was an article of a magazine, journal or other serial publication.  Now, expanding the scope to cover the broader publishing use cases, the unit-of-content is not so obvious.  This is particularly true when advertising material, blog or book content is added to the scope.

In order to refine what we mean by the generic term “article,” the PRISM Content Type Controlled Vocabulary has been developed.  A content type identifies the highest-level indicator of the nature of the asset that is tagged.  Some content types that describe the unit-of-storage include an advertisement, article, blog entry, book chapter, cover, masthead, introduction and navigational aid.

See The PRISM Controlled Vocabularies Specification [PRISMCVS] for complete documentation of the new PRISM Content Type Controlled Vocabulary.

In addition, the PRISM Genre Controlled Vocabulary has been enhanced in PRISM 3.0 to refine the intellectual description of core content types.  So if a unit of stored content is the content type “article,” we can refine the description by specifying that the genre is a “cover story” that is an “interview”, a “profile” or even a photo essay.

       abstract (refines article)

       acknowledgements (refines bookChapter)

       adaptation (refines article)

       advertorial (refines advertisement)

       analysis (refines article)

       answers (refines bookChapter or contentBlock)

       appendix  (refines bookChapter)

       authorBio  (refines bookChapter)

       autobiography (refines navigationAid)

       backCover (refines cover)

       bibliography  (refines bookChapter)

       biography (refines article)

       box (refines contentBlock)

       calendar (refines article)

       cartoon (refines contentBlock)

       chapter (refines bookChapter)

       chart (refines contentBlock)

       chronology (refines article)

       clarification (refines article or blogEntry)

       classifiedAd (refines contentBlock)

       column  (refines article or blogEntry)

       correction (refines article or blogEntry)

       coverPackageArticle  (refines article)

       coverStory  (refines article)

       dedication (refines bookChapter)

       department (refines article)

       diagram (refines contentBlock)

       electionResults  (refines article)

       essay (refines article)

       excerpt (refines article)

       faq (refines article)

       fashionShoot (refines article)

       feature  (refines article)

       featurePackageArticle  (refines article)

       fiction (refines article)

       financialStatement  (refines article)

       foreward (refines bookChapter)

       frontInsideCover (refines otherCover)

       glossary (refines bookChapter)

       horoscope (refines contentBlock)

       insideBackCover (refines otherCover)

       insideFrontCover (refines otherCover)

       interactiveContent (refines article)

       interview  (refines article)

       jumpPage  (refines article)

       layer (refines contentBlock)

       legalDocument  (refines contentBlock)

       letters (refines article)

       list (refines article)

       map (refines contentBlock)

       newsBulletin  (refines article)

       notice (refines article)

       obituary  (refines article)

       opinion  (refines article)

       other (refines any content type)

       photoEssay  (refines article)

       poem (refines contentBlock)

       poll (refines contentBlock)

       postscript (refines bookChapter)

       preface  (refines bookChapter)

       pressRelease (refines article)

       productDescription (refines article)

       profile  (refines article)

       puzzle (refines contentBlock)

       qAndA  (refines article)

       quiz (refines contentBlock)

       quotation (refines article)

       ranking (refines article)

       recipe (refines contentBlock)

       references  (refines bookChapter)

       reprint (refines article)

       resources  (refines article)

       response (refines article)

       review (refines article)

       schedule (refines article)

       scrubber (refines navigationAid)

       sectionList (refines navigationAid)

       sectionTableOfContents  (refines navigationAid)

       sidebar (refines contentBlock)

       stockQuote (refines contentBlock)

       supplementAdvertisement (refines advertisement)

       supplementArticle (refines article)

       supplementBackCover (refines otherCover)

       supplementFrontCover (refines other Cover)

       tableOfContents (refines navigationalAid)

       transcript (refines article)

       userComments  (refines article)

       userGeneratedContent (refines contentBlock)

       userReview  (refines article)

       wireStory  (refines article)

The unique identifier metadata block provides one identification mechanism for articles, chapters, blog entries, etc. and a second identification mechanism that is specifically designed for advertisements.  See Figure 3.3.

Figure 3.3 Unique Identifier Structure

At a minimum, each non-advertising unit of content must have a unique identifier specified using dc:identifier and a title.  In addition some other options have been included.  See Figure 2.4.

Figure 3.4 PSV Identification Metadata

Identification of Advertisements

At a minimum, each non-advertising unit of content must have a unique identifier and a title.  Because specifications from AdsML, the Ghent Work Group (www.gwg.org) Ad-ID (ad-id.org) and exist today for identifying ad material, nextPub has adopted those metadata fields for the unique identification of ads.  See Figure 3.5.

Figure 3.5 Unique Identification for Ad Materials

PSV description metadata provides descriptive information about the content.  This block is based on PRISM descriptive metadata fields along with some additional fields for describing advertising.  See Figure 3.6.

Figure 3.6 PSV Descriptive Metadata Structure

Any of the PRISM descriptive metadata may be used to describe an advertisement.  For example, we might want to specify a prism:industry or prism:organization featured in an advertisement.  But again other specifications, focusing specifically on describing advertisements already exist.  So those fields are also allowed as options for describing advertising materials.  See Figure 3.5.

Figure 3.7 PSV Advertising Description Metadata

Because nextPub seeks to define source content for publication categories far broader than just magazines, it is entirely possible that the source content may have originally been encoded to another existing XML tagging specification such as TEI or DocBook.  A new, generic metadata element has been added to support this use case.  The <psv:meta tag has three attributes to capture the outside metadata semantics:

• prefix=  specifies the namespace, or prefix from the source metadata schema
• name=  specifies the name of the metadata field
• content=  specifies the value for that field

See Figure 3.8.

Figure 3.8 PSV <meta Element

Note:  Reference the PRISM Dublin Core Metadata Specification V3.0 and the PRISM Metadata Specification V3.0 and the PRISM Ad Materials Metadata Specification v3.0 for definitions of the metadata fields for the description metadata block.

This metadata provides information about how the content is related to other content.  See Figure 3.9.

Figure 3.9 PSV Relations Metadata

Reference the PRISM Subset of Dublin Core Metadata Specification V3.0 for definitions of the PRISM metadata fields for the relations metadata block.

This metadata provides information about the usage rights for the content.  See Figure 3.10.

Figure 3.10 PSV Usage Rights Metadata

Reference the PRISM Usage Rights Metadata Specification V3.0 for definitions of the PRISM metadata fields for the usageRights metadata block.

PSV is made up of the text of an article or chapter along with objects that are often created independently.  For purposes of encoding, PSV identifies these objects by the generic term Components.  A photo, a video, a recipe and even the sidebar of an article may be considered to be a component.  Components often have their own descriptive metadata that must be captured in the source and that may even be delivered when content is packaged to be delivered to a distributor or device.

PSV has developed a mechanism for including component metadata in the metadata block and linking that metadata back to the component in the text.  This mechanism is described in detail in Section 9 of this Specification.

The concept behind PSV is that the source must be platform agnostic so that it can be selected from a CMS, styled and transformed into the format for the delivery channel.  In many cases, content will go to a variety of delivery channels at the same time.  So we can’t really track the platform of origin as we did with PRISM 2.1.  Instead we must track usage of each unit of content by the publication, platform and device.  We have also developed blocks to track the usage information based on a publication issue, article, website, supplement and information about other usage such as in a book.   See Figure3.11.

Figure 3.11 Where Used Metadata

3.4.8.1   Issue Information

The <psv:issueInfo block contains information about an issue of a magazine.  See Figure 3.12.

Figure 3.12  Issue Information Structure

3.4.8.2   Article Information

The <psv:articleInfo block contains information about an article within an issue.  This metadata should be used in conjunction with issue information or with website information in the case where the article was only published online.  See Figure 3.13.

3.13 PSV Article Information Structure

3.4.8.3   Website Information

The <psv:websiteInfo block contains information about the website where the content was used. See Figure 3.14.

Figure 3.14 PSV Website Information Structure

Note:  If a magazine article only appears online you must at a minimum provide the websiteInfo to specify the URL and the publication date.

3.4.8.4   Supplement Information

The <psv:supplementInfo block contains information about a supplement where the content was used. See Figure 3.15.

Figure 3.15 Supplement Information Structure

3.4.8.5   Book Information

The <psv:bookInfo block contains information about a book where the content was used. See Figure 3.16.

Figure 3.16 Book Information Structure

3.4.8.6   Chapter Information

The <psv:chapterInfo block contains information about the chapter of a book where the content was used.  This metadata should be used in conjunction with book information metadata.  See Figure 3.17.

Figure 3.17 Chapter Information Structure

3.4.8.7   Blog Information

The <psv:blogInfo block contains information about a blog where the content was used. See Figure 3.18.

Figure 3.18 Blog Information Structure

3.4.8.8   Blog Entry Information

The <psv:blogEntryInfo block contains information about an entry of a blog where the content was used.  This metadata should be used in conjunction with blog information metadata.  See Figure 3.19.

Figure 3.19 Blog Entry Information Structure

The specification for the PSV includes an HTML5-compliant <head structure in addition the <psv:metadata block that contains the metadata for the article.  This decision was made because the HTML5 <head structure contains elements that add functionality required for proper rendering and display of the elements in the body.

The HTML5 <head structure includes the title, base, link, script and style elements.  See Figure 3.20.

Figure 3.20 HTML5 Head Structure

The following HTML5 Head elements provide functionality to support display of the body of the article.

3.5.1.1   Title

The HTML5 <title tag specifies the title for a Web page:

<head>
<title>IDEAlliance Bulletin, September 9, 2011</title>
</head>

3.5.1.2   Base

The HTML5 <base tag specifies a default URL and a default target for all links

<head>
<base href="http://www.idealliance.org/bulletin/issue09092011" target="_blank" />
</head>

3.5.1.3   Link

The HTML5 <link tag defines the relationship between a document and an external resource, often a stylesheet.

3.5.1.4   Script

The HTML5 <script tag is used in the head when you want a script to be executed before the browser renders the page.

3.5.1.5   Style

The HTML5 <style tag is used in the head when you want a style applied before the browser renders a page.

<head>
<style type="text/css">
h1 {color:red}
p {color:blue}
</style>
</head>

It is the intent that all PSV metadata in the Source be captured within the <psv:metadata block using the <psv:meta tag and that it not be duplicated or replaced using the HTML5 <meta tag.  The HTML5 <meta tag has therefore not been included in the model for HTML5 <head in this PSV Specification.

This section provides summary of elements used for PSV XML source article content encoding.    In moving away from the PRISM/PAM XML model to an HTML5-compliant model for coding the body of an article, we must take advantage of the new HTML5 elements that provide semantics that are useful in coding an article.  HTML5 Working Draft describes the new <article tag as:

“The <article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.”

The HTML5 coding for the body of the article should begin with the new HTML5 element <article.  The W3C definition of <article is quite broad. In concept <article can easily be applied to identify any independent unit of published content from an article to a blog entry or even the chapter of a book. See Figure 3.21.

Figure 3.21 HTML5 Article Model

While all HTML5 tags are available for coding an article, several best practices are recommended to capture the nextPub/PRISM semantics.  Those recommendations are outlined in the following sections.

Note: Currently no schema is available for the HTML5 Draft.  Images in this Specification were generated from a Draft HTML5 schema developed especially to illustrate the PSV Recommendations.

We recommend the use of the new HTML5 <aside tag for those structures where the content is “aside” from the content of the article.  These structures include box, sidebar, footnotes and pull quote.

The HTML5 Working Draft describes <aside as:

“The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.”

The following chart provides the semantic class values for HTML5 tags and a suggestion about where the use of the class attributes is appropriate.  Reference the PRISM Controlled Vocabularies Specification V3.0 [PRISMCVS] for complete documentation about the PSV Class Controlled Vocabulary.

** indicates a new class in PRISM 3.0

Note: the PSV content class CV terms have a prism: prefix to indicate the namespace from which the value was taken.  This is informational only and does not imply XML namespace processing will occur.

Some of the semantic richness provided by PRISM is captured by applying inline class attributes.  The recommended approach is to use the <span element with a class attribute with values from a PSV Inline Class Controlled Vocabulary. Reference the PRISM Controlled Vocabularies Specification V3.0 [PRISMCVS] for complete documentation about the PSV Inline Class Controlled Vocabulary.

3.6.4.1   Inline Classes

** indicates a new inline class

Note: The PSV inline content class CV terms have a prism: prefix to indicate the namespace from which the value was taken.  This is informational only and does not imply XML namespace processing will occur.

The< nav element should contain a set of navigation links, either to other pages or fragment identifiers in the current page. Referencing it with semantic class names is simple.

Here is some sample content coded in HTML5:

This section provides documentation and guidelines for encoding PSV media blocks.  The media block concept was initially based on the pam:media element currently used in the existing PRISM Aggregator Message.  A media block presents one or more media objects along with ancillary text content so it is what HTML5 calls a “grouping” structure. 

After studying HTML5, we believe the <figure element contains richness required to express the wide variety of media blocks that we require for tablet editions.  See Figure 3.13. 

Figure 5.1 Figure Model

An HTML5 figure is a media block typically presenting one or more media objects along with ancillary text content.  This means that the figure is what HTML5 calls a “grouping structure.” 

A <figure is not a required to embed rich media objects in an article.  If you wish to link a rich media object right into the content stream you may use an <a tag to link to the object, just as you do on a Web page.  You can also use <img, <audio, or <video directly in the content stream.  If you want to include other content associated with the media, such as a caption, or if you need to include more than a single media object, then you should use the HTML5 <figure to do so.

Semantics (presentation types) have been developed to express the intended type of media block being specified with the HTML5 <figure element. 

Reference the PRISM Controlled Vocabulary Specification V3.0 for complete documentation about the PRISM Presentation Type Controlled Vocabulary.

Some of presentation type classes include:

Note: the PSV Presentatation Type CV terms have a prism: prefix to indicate the namespace from which the value was taken.  This is informational only and does not imply XML namespace processing will occur.

The following chart provides the class values for figure content (text) and a suggestion about where the use of these class attributes is appropriate.

Here is a simple media block tagged with HTML5:

Note: As well as providing semantic meaning to an HTML5 structure, the value of the class= attribute can be used to link in a formatting style from a CSS style sheet.

HTML5 introduces new features that are designed to make it easy to include and handle multimedia and graphical content on the web without having to resort to proprietary plug-ins and APIs.  One of these features is a robust set of “Event” attributes. 

When someone visits a website or uses an app on a tablet, they do things like click on text or an image, touch, swipe or tap.  These are examples of what JavaScript calls an event.  HTML5 has added a broad range of specifications for event handlers expressed as a value of an event attribute.  These attributes can be used to trigger a JavaScript or VBScript code to give action to the display.

At one time, the PSV Media Object team sought to develop a set of “display hint” attributes to record intention for the functionality of any multimedia object in a publication.  However, PSV has opted to go directly to HTML5 multimedia functionality and use the HTML5 events attributes to serve the same purpose without adding an additional coding layer to be interpreted by the application. 

HTML5 Event Attributes can trigger scripts for the following:

• Window Events
• Forms Events
• Mouse Events
• Keyboard Events
• Touch Events

Three event types are being developed by the W3C Touch Events Working Group:

• touchstart Event:  This event can trigger a script when the user places a touch point on the touch surface.
• touchmove Event: This event can trigger a script when the user moves a touch point along the touch surface.
• touchend Event:  This event can trigger a script when the user removes a touch point from the touch surface.

By using HTML5 as an encoding base, PSV will access the power within HTML5 to create dynamic, multimedia displays.

In PSV, the figure as well as each media object (such as a photo or a video) is considered to be a Component.  Metadata for each component is encoded using the PSV component metadata encoding model.  See Section 9.

Sometimes media models are complex, that is, made up of more than one rich media object.  An example of this is a slideshow.  In this case one must code a <figure within a <figure.  See the following example coding for a slideshow:

This section provides documentation and guidelines for encoding PSV recipes.  The PSV recipe is a structure within an article that has special recipe semantics.  In addition, a recipe has unique metadata that should be captured in the source.

After studying HTML5, we believe that a recipe will be either a <div, a <section, or even an <aside with the class=”recipe.”

Note: Recipes contained with an article are not required to be coded in the stream of article content.  Recipes may also be coded as a standalone article type and pulled into the article using an <a tag.

When a recipe appears in a magazine article, it has its own unique semantics to be captured.  Like the semantics of the general article, the recommendation of PSV is to capture the semantics using the class= attribute of HTML.  The following chart provides some of the class values for recipe text and a suggestion about where the use of the recipe class attributes is appropriate.

Reference the PRISM Recipe Metadata Specification V3.0 [PRISMRMS] and PRISM Controlled Vocabulary Specification V3.0 [PRISMCVS] for complete documentation about the recipe class CV.

Note: the PSV Recipe Class CV terms have a prm: prefix to indicate the namespace from which the value was taken.  This is informational only and does not imply XML namespace processing will occur.

Here is the recipe coded in the <body with HTML5:

In the previous example we were able to bring the content of the recipe into HTML5 tagging quite easily.  However the metadata for the recipe was lost.  In nextPub, each recipe is considered to be a Component.  Metadata for each recipe, or component, is encoded using the PSV component metadata encoding model.  See Section 9.

One consideration of a nextPub model is the inclusion of Ad Materials.  It is most likely that Ads will not be stored in the source XML database.  However this model provides us with a starting point for including Ad Material with source content for delivering it to devices. 

If the PSV content unit is advertising material, it is expected that prism:contentType will be given a value of “advertisement.”  In addition each advertisement needs to have identification within the ad identification block of article identification metadata.

Note:  For PSV Version 1.0, it is assumed that only full page advertisements are within scope of the specification.

Two workflows are required to support ad placement in any publication, print or on a tablet.  The first is the transaction or ad booking workflow and the second is the materials production workflow.  Metadata from each of these workflows is appropriate for inclusion in the XML Source and for materials delivered to distributors and devices.  Both are represented in the PSV advertising description model. 

Note: Many advertising metadata fields have been defined by AdsML/GWG, Ad-ID or both.  PSV b is also using some fields from the new PRISM Advertising Metadata Namespace (prism-ad:) when appropriate fields from established namespaces are not available.

Just as any article needs a unique identifier, so does an advertisement.  PSV requires the AdsML PrimaryMaterialsID and allows an optional ID Type field to specify the type of identifier that is used for this ad.  One type of unique identifier is the Ad-ID.  In addition, a human readable title for the advertisement is also required.  See Figure 3.22.

Figure 3.22 Ad Identification Block Structure

Reference the PRISM Advertising Metadata Specification V 3.0 0 [PRISMAMS] and the PRISM Basic Metadata Specification V3.0 [PRISMBMS] for definitions of the metadata fields for the PSV ad identification block.

Two workflows are required to support ad placement in any publication, print or on a tablet.  One workflow is the transaction or ad booking workflow and another is the materials production workflow.  Both are represented within the PSV Ad Description metadata block. 

3.9.3.1   Ad Materials

Metadata from the materials production workflow is found in the Ad Materials block.  See Figure 3.23.

Figure 3.23 Ad Materials Structure

Reference the PRISM Advertising Metadata Specification V 3.0 0 [PRISMAMS] and the PRISM Basic Metadata Specification V3.0 0 [PRISMBMS]for definitions of the metadata fields for the PSV ad materials block.  Contents of this metadata block were designed to be compatible with required fields from Ad-ID.

3.9.3.2   Ad Booking

Two workflows are required to support ad placement in any publication, print or on a tablet.  One workflow is the transaction or ad booking workflow and another is the materials production workflow.  Metadata from the ad booking workflow is found in the Ad Booking block.  See Figure 3.24.

Figure 3.24 Ad Booking Structure

Reference the PRISM Ad Materials Metadata Specification V 3.0 for definitions of the metadata fields for the PSV ad booking block.  Contents of this metadata block were designed to be compatible with required fields from Ad-ID.

This example shows how an advertisement would be encoded for PSV XML Source.

Here is an example of how an ad might be coded with HTML5 in the body.  Note that because we set the prism:contentType to “advertisement” we know that the article is an advertisement.  

The PRISM Source Vocabulary Specification defines rich semantic encoding for source content so that it can be aggregated, transformed and served to a wide variety of output devices including print, eReaders, mobile tablet devices and beyond.  The XML Source is made up of the text of the article along with objects that are created independently of the article text and can stand on their own.  For purposes of encoding, PSV identifies these objects by the generic term Components.  A photo, a video, a recipe and even a sidebar may be considered to be an article component.

Because components within a PSV article are independent or can stand alone, these components often have their own descriptive metadata that must be captured in the source and that may even be delivered when content is packaged to be delivered to a distributor or device.  HTML5 technically only allows for metadata in the <head but not in the body where article components occur.  If the user wishes to include component-level metadata in the XML content source, the metadata for each component must be placed in the <psv:metadata block and linked to the component in the HTML5-compliant body by matching the id= in the body to a refines= attribute in the components block.  Note that the refines= syntax matches that used in EPUB 3 where refines= is a “URI”. This means that the value is preceded by a # sign to indicate the path for the link being specified.

If, for example, a photo has metadata such as the name of the photographer or the person pictured in the photograph, this metadata should be encoded as part of the PSV in the components metadata block and linked to the photo by referencing the ID of the photograph.  Likewise, metadata about a recipe such as the name of the chef that created the recipe or the type of cuisine should be encoded as part of the PSV components metadata block and linked to the recipe.

Metadata for any PSV component should be captured in the <psv:components block of the <psv:metadata element.  This block provides a generic approach for encoding component metadata from any PRISM vocabulary metadata  or even outside metadata domains.  See Figure 3.25.

Figure 3.25 Components Metadata Structure

3.10.2.1 Linking a Component to Its Metadata

Metadata for any component is linked by matching the id= attribute on the component as it appears in the body to the components metadata block using a refines= attribute.  This means that if an entity such as an image, video or recipe has metadata, it must have a unique identifier (id= ) specified so the link can be made.

Here is an image coded in HTML5.  Note that an id has been assigned to the image so it can be linked to component metadata for that image in the <psv:metadata element:

Here is how the metadata is coded in the <psv:metadata element. Note that the refines= attribute on the <components element this metadata to the image in the body:

Here is the recipe coded with HTML5.  Note the id= attribute has been specified in order to link the recipe with the metadata in the <psv:metadata element.

Here is how the metadata would be pulled into the head.  Note that the idref on the recipe metadata block links this metadata to the recipe section in the body:

Appendix A Sample Tagging without Components

Appendix B References 

B.1     Normative References for PRISM and PSV Specifications

[AAT] Getty Art and Architecture Thesaurus.

[ADSML-AT] AdsML Ad Ticket 1.0 May 2011

[DCMI] Dublin Core Metadata Element Set, Version 1.1: Reference Description.

[DCMI-TERMS] Dublin Core Metadata Terms, 2005-01-10.

[DOI-HB] Digital Object Indentifier Handbook, Version 4.4.1, October 2006,

[EPUB3] International Digital Publishing Forum (IDPF), EPUB Version 3.0 2011.

[HTML5] HTML5: A Vocabulary and Associated APIs for HTML and XHTML Working Draft March 2012

[IETF-MIMETYPES] Internet Assigned Numbers Authority (IANA); Internet Media Types.

[IMAGEGUIDE] PRISM Working Group 2012, Guide to PRISM Metadata for Images Image_Guide.pdf

[PSVSO] nextPub Working Group, PRISM Source Vocabulary Specification Overview.

[IPTC-NEWSML] International Press and Telecommunications Council, NewsML Specification & Documents;

[IPTC-NITF] International Press and Telecommunications Council, News Industry Text Format.

[ISO-639] ISO 639 - Codes for the representation of names of languages.

[ISO-3166] ISO 3166 - Codes for the representation of names of countries and their subdivisions.

[NAICS] North American Industry Classification System; 1997.

[RFC-3066] H. Alvestrand; Tags for the Identification of Languages; January 2001.

[PAMGUIDE] PRISM Working Group, 2012, Guide to the PRISM Aggregator Message V. 2.2

[PAMPSVGUIDE] nextPub Working Group, 2012, PAM to PSV Guide V 1.0.

[PRISMADMS] PRISM Working Group, 2012, PRISM Advertising Metadata Specification v3.0

[PRISMBMS] PRISM Working Group, 2012, The PRISM Basic Metadata Specification V3.0

[PRISMCOMP] PRISM Working Group, 2012, PRISM Compliance, V 3.0

[PRISMIMS] PRISM Working Group 2012, The PRISM Image Metadata Specification

[PRISMRMS] PRISM Working Group, 2012, The PRISM Recipe Metadata Specification.

[PRISMDCMS] PRISM Working Group, 2012, The PRISM Subset of the Dublin Core Namespace V 3.0,

[PRISMURMS] PRISM Working Group, 2012, The PRISM Usage Rights Metadata Specification V3.0,

[PRISMCVMS] PRISM Working Group, 2012, The PRISM Controlled Vocabulary Markup Specification V 3.0

[PRISMCVS] PRISM Working Group, 2012, The PRISM Controlled Vocabularies Specification

[PSVS] nextPub Working Group, 2012, PRISM Source Vocabulary Specification V1.0

[PSVSO] nextPub Working Group, 2012, PRISM Source Vocabulary Specification Overview V1.0

[PSVMS] nextPub Working Group, 2012, PRISM Source Vocabulary Markup Specification V 1.0

[RECIPEGUIDE] PRISM Working Group, 2012, Guide to PRISM Recipe Metadata and XML Encoding Guide

[RIGHTSGUIDE] PRISM Working Group, 2012, Guide to PRISM Usage Rights

[RFC-2396] IETF, Uniform Resource Identifiers (URI): Generic Syntax, Internet RFC 2396.

[TGN] Getty Thesaurus of Geographic Names.

[W3C-DATETIME] Misha Wolf, Charles Wicksteed; Date and Time Formats; W3C Note

[W3C-RDF] Ora Lassila, Ralph R Swick, Resource Definition Framework (RDF) Model and Syntax Specification.

[W3C-RDFS] Dan Brickley, R.V. Guha (eds.), Resource Description Framework (RDF) Schema Specification 1.0, 10 February 2004

[W3C-XML] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen (eds.), Extensible Markup Language (XML)

[W3C-XML-NS] Tim Bray, Dave Hollander, Andrew Layman (eds.); Namespaces in XML.

[XMP] Adobe Systems, XMP Specification.

Non-Normative References for PRISM and PSV Specifications

[ISO-8601] ISO (International Organization for Standardization)1998..

[PRISMIMS] PRISM Working Group, 2012, The PRISM Inline Markup Specification V3.0

[PRISMPAMMS] PRISM Working Group, 2010, The PRISM PAM Markup Specification,

[RDF-FRIENDLY] Making Your XML RDF-Friendly by John Cowan and Bob DuCharme

[RDF-SEMANTICS] RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at https://www.w3.org/TR/rdf-mt/ .

[XML-SCHEMA1] XML Schema Part 1: Structures W3C Recommendation, World Wide Web Consortium, 2 May 2001. This version is https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . The latest version is available at https://www.w3.org/TR/xmlschema-1/ .

[XML-SCHEMA2] XML Schema Part 2: Datatypes, W3C Recommendation, World Wide Web Consortium, 2 May 2001.This version is https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ . The latest version is available at https://www.w3.org/TR/xmlschema-2/ .

B.2     Non-Normative References for PRISM and PSV Specifications

[ISO-8601] ISO (International Organization for Standardization), ISO 8601:1988 (E) Data elements and interchange formats - Information interchange - Representation of dates and times, 1998.

[PRISMIMS] PRISM Working Group, 2012, The PRISM Inline Markup Specification V3.0,

[PRISMPAMMS] PRISM Working Group, 2010, The PRISM PAM Markup Specification

[RDF-FRIENDLY] Making Your XML RDF-Friendly by John Cowan and Bob DuCharme

[RDF-SEMANTICS] RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, https://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at https://www.w3.org/TR/rdf-mt/ .

[XML-SCHEMA1] XML Schema Part 1: Structures W3C Recommendation, World Wide Web Consortium, 2 May 2001. This version is https://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . The latest version is available at https://www.w3.org/TR/xmlschema-1/ .

[XML-SCHEMA2] XML Schema Part 2: Datatypes, W3C Recommendation, World Wide Web Consortium, 2 May 2001.This version is https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ . The latest version is available at https://www.w3.org/TR/xmlschema-2/