This specification is freely redistributable, and conforming applications may be implemented without fee. Implementations may not add any elements, attributes, or other items to the PRISM namespaces and vocabularies. All additions, amendments, and alterations must be made in other XML namespaces.

For an ongoing list of known errors, workarounds, and issues for future work, please consult the errata page:

Table Of Contents

1 Introduction.. 7

1.1 Purpose and Scope 7

1.2 Relationship to Other Specifications 7

1.3 Additional Issues. 9

1.4 Definitions 10

1.5 Structure of this Document10

2 Overview 12

2.1 Travel Content Syndication Scenario. 12

2.2 Basic Metadata. 12

2.3 Embedded vs. External Metadata. 13

2.4 Controlled Vocabularies 14

2.5 Relations 16

2.6 Resource Type and Category. 16

2.7 Rights and Permissions. 17

3 Elements by Functional Group. 23

3.1 General Purpose Elements. 23

3.2 Provenance 23

3.3 Timestamps 23

3.4 Subject Description. 24

3.5 Resource Relationships 24

3.6 Rights and Permissions. 25

3.7 Controlled Vocabularies 26

3.8 PRISM In-line Markup 27

Part II: Normative Specification.. 28

4 Framework.. 29

4.1 Requirement Wording Note 29

4.2 Behavior of PRISM-compliant Software. 29

4.3 Identifying PRISM Content29

4.4 Namespace and Vocabulary Identifiers. 29

4.5 Identifiers 31

4.6 Cardinality and Optionality. 31

4.7 Automatic Creation of Inverse Relations. 31

4.8 PRISM Profile of the Resource Description Framework. 32

5 Element Definitions. 35

5.1 XML Entities Used In Definitions. 35

5.2 Dublin Core Namespace. 36

5.3 Basic PRISM Namespace. 43

5.4 PRISM Rights Language. 53

5.5 PRISM Inline Markup Namespace. 56

5.6 PRISM Controlled Vocabulary Namespace. 58

6 Controlled Vocabularies 62

6.1 Rights and Usage Vocabularies 62

6.2 Resource Type Vocabulary (presentation style) 62

6.3 Resource Category Vocabulary (intellectual genre) 65

Appendix A: Bibliography.. 67

Part I: Introduction and Overview

(non-normative)

Introduction

Purpose and Scope

The Publishing Requirements for Industry Standard Metadata (PRISM) specification defines an XML metadata vocabulary for syndicating, aggregating, post-processing and multi-purposing magazine, news, catalog, book, and mainstream journal content. PRISM provides a framework for the interchange and preservation of content and metadata, a collection of elements to describe that content, and a set of controlled vocabularies listing the values for those elements.

The working group focused on metadata for:

General-purpose description of resources as a whole

Specification of a resource’s relationships to other resources

Definition of intellectual property rights and permissions

Expressing inline metadata (that is, markup within the resource itself).

Like the ICE protocol [ICE], PRISM is designed be straightforward to use over the Internet, support a wide variety of applications, not constrain data formats of the resources being described, conform to a specific XML syntax, and be constrained to practical and implementable mechanisms.

The PRISM group’s emphasis on implementable mechanisms is key to many of the choices made in this specification. For example, the elements provided for describing intellectual property rights are not intended to be a complete, general-purpose rights language that will let unknown parties do business with complete confidence and settle their accounts with micro-transactions. Instead, it provides elements needed for the most common cases encountered when one publisher of information wants to reuse material from another. Its focus is on reducing the cost of compliance with existing contracts that have been negotiated between a publisher and their business partners.

Relationship to Other Specifications

XML

PRISM metadata documents are an application of XML [W3C-XML]. Basic concepts in PRISM are represented using the element/attribute markup model of XML. The PRISM specification makes use of additional XML concepts, such as namespaces[W3C-XML-NS].

Resource Description Framework (RDF)

The Resource Description Framework [W3C-RDF] defines a model and XML syntax to represent and transport metadata. PRISM uses a simplified profile of RDF for its metadata framework. Thus, PRISM compliant applications will generate metadata that can be processed by RDF processing applications. However, the converse is not necessarily true. The behavior of applications processing input that does not conform to this specification is not defined.

Dublin Core (DC)

The Dublin Core Metadata Initiative [DCMI] established a set of metadata to describe electronic resources in a manner similar to a library card catalog. The Dublin Core includes 15 general elements designed to characterize resources. PRISM uses the Dublin Core and its relation types as the foundation for its metadata. PRISM also recommends practices for using the Dublin Core vocabulary.

NewsML

NewsML [IPTC-NEWSML] is a standard from the International Press Telecommunications Council (IPTC) aimed at the transmission of news stories and the automation of newswire services. PRISM focuses on describing content and how it may be reused. While there is some overlap between the two standards, PRISM and NewsML are largely complementary. PRISM’s controlled vocabularies have been specified in such a way that they can be used in NewsML. The PRISM working group and the IPTC are working together to investigate a common format and metadata vocabulary to satisfy the needs of the members of both organizations.

News Industry Text Format (NITF)

NITF [IPTC-NITF] is another IPTC specification. NITF provides a DTD designed to mark up news stories. PRISM is a metadata vocabulary designed to describe resources and their relationship to other resources. Although NITF has some elements to specify metadata and header information that are duplicated in PRISM, the two standards are largely complementary. Where there is overlap, such as with PRISM’s inline markup, it is noted in the specification.

Information and Content Exchange (ICE)

The Information and Content Exchange protocol manages and automates syndication relationships, data transfer, and results analysis. PRISM complements ICE by providing an industry-standard vocabulary to automate content reuse and syndication processes. To quote from the ICE specification [ICE]:

Reusing and redistributing information and content from one Web site to another is an ad hoc and expensive process. The expense derives from two different types of problem:

Before successfully sharing and reusing information, both ends need a common vocabulary.

Before successfully transferring any data and managing the relationship, both ends need a common protocol and management model.

Successful content syndication requires solving both halves of this puzzle.

Thus, there is a natural synergy between ICE and PRISM. ICE provides the protocol for syndication processes and PRISM provides a description of the resource being syndicated, which can be used to personalize the delivery of content to tightly-focused target markets.

The two working groups have recently defined the means for PRISM to describe ICE items and for ICE to convey PRISM descriptions.

RSS (RDF Site Summary) 1.0

RSS (RDF Site Summary) 1.0 [RSS] is a lightweight format for syndication and descriptive metadata. Like PRISM, RSS is an XML application, conforms to the W3C's RDF Specification and is extensible via XML-namespace and/or RDF based modularization. The RSS-WG is currently developing and standardizing new modules.

The primary application of RSS is as a very lightweight syndication protocol for distributing headlines and links. It is very easy to implement, but does not offer the rich negotiation and reliable delivery features of ICE.

eXtensible Rights Markup Language (XrML)

XrML [XRML] is a specification developed by ContentGuard, Inc. It specifies the behavior of trusted digital rights management systems and repositories. Unlike XrML, PRISM assumes that the sender and receiver of a PRISM communication already have a business arrangement that is specified in a contract. PRISM’s focus is on lowering the costs of complying with that agreement. Thus, it provides a standard means of expressing common terms and conditions. XrML takes on a much harder problem, controlling the behavior of end-user applications and devices such as printers and tape drives to prevent unauthorized reuse of the content. PRISM specifies as little as possible about the internal behavior of systems. Thus, PRISM’s treatment of derivative use rights is complimentary to, but separate from, the rights and uses that are specified in XrML.

XTM (XML Topic Maps)

XTM is an XML representation of ISO Topic Maps [ISO-13250], an approach for representing topics, their occurrences in documents, and the associations between topics. This is very similar to PRISM’s use of controlled vocabularies.

XTM documents require that topics use a URI as a unique identifier. PRISM descriptions can directly cite XTM topics when there is a need to use them where PRISM allows values from controlled vocabularies. There is also a simple mapping between the XTM format and the PRISM group’s simple XML format for controlled vocabularies.

Additional Issues

Redundancy

Redundancy is a necessary consequence of re-using existing work. For example, when sending PRISM data in an ICE payload, there will be duplication of PRISM timestamp information and ICE header data. Therefore, in some cases, the same information will be specified in more than one place. This is normally a situation to be avoided. On the other hand, PRISM descriptions need to be able to stand alone, so there is no way to optimize PRISM’s content for a particular protocol. The working group decided that redundancy should neither be encouraged nor avoided.

Exchange Mechanisms

PRISM specifies a file format, and does not define or impose any particular exchange mechanism. There are many ways to exchange the descriptions and the content they describe. Developers of such exchange protocols should consider the following factors:

Easily separable content: A tool that provides metadata will need to get at this information quickly. If metadata is mixed with content, these tools will have to always scan through the content.

Reference vs. Inline content: Referencing content is visually clean, but presents a challenge with access (security, stale links, etc). Inline requires larger data streams and longer updates in the face of changes.

Encoding. Depending on the choice of format, encoding of the content may be necessary. Extra computation or space will be needed.

Security

The PRISM specification deliberately does not address security issues. The working group decided that the metadata descriptions could be secured by whatever security provisions might be applied to the resource(s) being described. PRISM implementations can achieve necessary security using a variety of methods, including:

Encryption at the transport level, e.g., via SSL, PGP, or S/MIME.

Sending digitally signed content as items within the PRISM interchange format, with verification performed at the application level (above PRISM).

Rights Enforcement

The PRISM specification does not address the issue of rights enforcement mechanisms. The working group decided that the most important usage scenarios at this time involved parties with an existing contractual relationship. This implied that the most important functionality required from PRISM’s rights elements was to reduce the costs associated with clearing rights, not to enable secure commerce between unknown parties. Therefore the PRISM specification provides mechanisms to describe the most common rights and permissions associated with content, but does not specify the means to enforce compliance with those descriptions. Essentially, the goal is to make it less expensive for honest parties to remain honest, and to let the courts serve their current enforcement role.

Definitions

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.

Authority File	One of the forms of a controlled vocabulary, in which a list of uniquely identified entities, such as companies, authors, countries, employees, or customers, is maintained over time.
Content	Content, as it is used in the PRISM specification is a non-normative term assumed to be a resource or a collection of resources.
Content Provider	A publisher, business, portal site, person or entity making content available in any medium.
Controlled Vocabulary	A list of uniquely identified terms with known meaning. The list itself has a defined maintenance procedure and restricted update access. For example, an employee database is one type of controlled vocabulary. The list of terms (staff names) is uniquely identified (employee number) and is maintained by a known procedure and staff (the HR department). There are two major types of controlled vocabularies - authority files and taxonomies.
Metadata	Information about a resource. In this specification, metadata is expressed as one or more properties.
Property	A field with a defined meaning used to describe a resource. A property plus the value of that property for a specific resource is a statement about that resource. [W3C-RDF]
Resource	Text, graphics, sound, video or anything else that can be identified with a URI or other identification scheme. The PRISM specification uses this term because it is not used in casual writing, so it can be used unambiguously in the PRISM specification.

Structure of this Document

The document is organized into two parts, plus an appendix. Part 1 is non-normative, providing an introduction to, and tutorial overview of, the specification. Despite being non-normative, there are occasional statements using the key words MUST, SHOULD, MAY, etc. Those statements will be repeated in Part 2, the normative portion of the specification.

Part 1 contains three sections. Section 1 provides this general introduction and establishes some of the context for the PRISM specification. Section 2 provides a tutorial for the major features of the spec, using a series of examples around a common scenario. Section 3 provides a quick reference to the elements defined in the specification, organized by functional group. Because elements can be used for multiple functions, they may be repeated in multiple tables.

Part 2 also contains three sections. Section 4 describes PRISM’s framework for identifiers, its profile (restricted subset) of RDF, and various other normative requirements on instances of the PRISM format. Section 5 gives normative definitions for the XML elements and attributes in the namespaces PRISM defines. Non-normative definitions, along with PRISM-recommended cataloging rules, are provided for the XML elements and attributes from namespaces PRISM recommends, but does not define, such as the Dublin Core. Section 6 defines vocabularies that PRISM uses as controlled values for various properties.

Appendix A provides a bibliography, which is also divided into normative and non-normative sections.

Overview

This section provides a non-normative overview of the PRISM specification and the types of problems that it addresses. It introduces the core concepts and many of the elements present in the PRISM specification by starting with a basic document with Dublin Core metadata, then using PRISM metadata elements to create richer descriptions of the article.

Although the PRISM specification contains a large number of elements and controlled vocabulary terms, most of them are optional. It is not necessary to put forth a large amount of effort to apply metadata to every resource, although it is possible to apply very rich metadata to resources whose potential for reuse justifies such an investment.

Travel Content SyndicationScenario

Wanderlust, a major travel publication, has a business relationship with travelmongo.com, a travel portal. After Wanderlust goes to press, they syndicate all of their articles and sidebars to content partners like travelmongo.com. Like many other publications, Wanderlust does not have the right to resell all of their images, because some of them have been obtained from stock photo agencies.

When Wanderlust creates syndication offers, an automated script searches through the metadata for the issue’s content to ensure that anything that cannot be syndicated is removed from the syndication offer with alternatives substituted when possible. Since Wanderlust tags their content with rights information in a standard way, this process happens automatically using off-the-shelf software.

Because Wanderlust includes standard descriptive information about people, products, places and rights when they syndicate their content, travelmongo.com can populate their content management system with all the appropriate data so that the articles can be properly classified and indexed. This reduces the cost to travelmongo.com of subscribing to third party content and makes content from Wanderlust even more valuable for them.

Basic Metadata

The elements in the Dublin Core form the basis for PRISM’s metadata vocabulary. This simple PRISM document uses some Dublin Core elements to describe a photo taken on the island of Corfu:

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845" />

<dc:description>Photograph taken at 6:00 am on Corfu with two models

</dc:description>

<dc:title>Walking on the Beach in Corfu</dc:title>

<dc:creator>John Peterson</dc:creator>

<dc:contributor>Sally Smith, lighting</dc:contributor>

<dc:format>image/jpeg</dc:format>

</rdf:Description>

</rdf:RDF>

PRISM descriptions are XML documents [W3C-XML], thus they begin with the standard XML declaration: <?xml version=”1.0”?>. A character encoding may be given if needed. As indicated by the two attributes beginning with ‘xmlns:’, PRISM documents use the XML Namespace mechanism [W3C-XML-NS]. This allows elements and attributes from different namespaces to be combined. Namespaces are the primary extension mechanism in PRISM. PRISM-compliant applications MUST NOT throw an error if they encounter unknown elements or attributes. They are free to delete or preserve such information, although recommended practice is to retain them and pass them along.

PRISM descriptions are compliant with the RDF constraints on the XML syntax. Thus, they begin with the rdf:RDF element.

PRISM requires that resources have unique identifiers. In the above example, the photo is identified by a URI in the rdf:about attribute of the rdf:Description element. The dc:identifier element can be used for other identifiers, such as ISBN numbers or system-specific identifiers. In the above example, the dc:identifier element contains an asset ID for Wanderlust’s asset management system.

PRISM follows the case convention adopted in the RDF specification. All elements, attributes and attribute values typically begin with an initial lower case letter, and compound names have the first letter of subsequent words capitalized. Element types may begin with an uppercase letter when they denote Classes in the sense of the RDF Schema [W3C-RDFS]. Only one of the elements in the PRISM namespace, pcv:Descriptor, does so. PRISM uses a simple naming convention. We avoid abbreviations, use American English spelling, and make the element names into nouns (or pseudoNounPhrases, because of the case convention) in singular form.

PRISM uses the convention of placing property values that are URI references, such as in the dc:identifier element in the example above, in the rdf:resource attribute. Prose or non-URI values are given as element content, as seen in the dc:description element. This allows automated systems to easily determine when a property value is a URI reference.

Embedded vs. External Metadata

For the most part, PRISM assumes that its descriptions are transferred as complete, standalone, XML documents that describe other files. But it is also possible to embed PRISM descriptions in a file. The example below shows a sample of a simple XML file, which contains an embedded PRISM description

<?xml version="1.0" encoding="UTF-8"?>

<doc>

<p>Fourscore and seven years ago, our fathers brought forth on this

continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.

</p>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="">

<dc:description>Start of the Gettysburg Address</dc:description>

<dc:creator>Abraham Lincoln</dc:creator>

</rdf:Description>

</rdf:RDF>

</doc>

A Brief Digression on Identifiers

Note that the empty string is given as the value of the rdf:about attribute. This means that the PRISM description is about the current file. The value of the rdf:about attribute is required to be a URI reference – either absolute or relative. By definition, relative URIs are relative to an absolute URI known as the base. By default, that base URI is the URI of the containing document. So, in this case, the relative URI reference is the empty string, meaning that it does not modify the base URI. Therefore, the rdf:about attribute refers to the current document.

It is also possible to use the new xml:base attribute[W3C-XML-BASE] to set the base URI reference. That attribute will be used in several examples in this document. However, readers are cautioned that the XML BASE specification is not yet a full Recommendation of the W3C, although it seems very likely to be passed in its current form. Readers are also cautioned that because it is so new, very few XML implementations will support it at this time. Therefore, creators of PRISM descriptions should be cautious about using it for the near future.

A Brief Digression on Intent

This example illustrates another important point. Note that the name given in the dc:creator element is “Abraham Lincoln”, not the name of the person who actually created the XML file and entered Lincoln’s famous line into it. There are applications, such as workflow, quality assurance, and historical analysis, where it would be important to track the identity of that individual. However, none of those are problems PRISM attempts to solve. PRISM’s purpose is to describe information for exchange and reuse between different systems, but not to say anything about the internal operations of those systems. The PRISM working group decided that workflow was an internal matter. This focus on a particular problem allows PRISM descriptions to avoid some thorny issues that more general specifications must address.

Controlled Vocabularies

Property values in PRISM may be strings, as shown above, or may be terms from controlled vocabularies. Controlled vocabularies are an important extensibility mechanism. They also enable significantly more sophisticated applications of the metadata. As an example, consider the two Descriptions below. The first provides a basic, human-readable, value for the dc:creator element, telling us that the Corfu photograph was taken by John Peterson. The second example appears harder to read, because it does not give us John Peterson’s name. Instead, it makes reference to John Peterson’s entry in the employee database for Wanderlust.

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:creator>John Peterson</dc:creator>

...

</rdf:Description>

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:creator rdf:resource=”http://wanderlust.com/emp3845”>

...

</rdf:Description>

That employee database is an example of a controlled vocabulary – it keeps a list of terms (employee names). It has a defined and controlled update procedure (only authorized members of the HR department can update the employee database, and all changes are logged). It uses a unique identification scheme (employee numbers) to handle the cases where the terms are not unique (Wanderlust might have more than one employee with a name like “John Peterson”). It can associate additional information with each entry (salary, division, job title, etc.)

The unique identifier is one of the keys to the power behind the use of controlled vocabularies. If we are given metadata like the first example, we are limited in the types of displays we can generate. We can list Wanderlust’s photographs, sorted by title or by author name. By using the employee database, we can generate those, but also lists organized by department, job title, salary, etc. We also avoid the problems around searching for common names like “John Smith”, dealing with name changes such as those due to marriage and divorce, and searching for items that have been described in other languages. Finally, content items are easier to reuse if they have been coded with widely adopted controlled vocabularies, which increases their resale value.

Defining additional vocabularies for specialized uses is a way to extend descriptive power without resorting to prose explanations. This makes them far more suited to automatic processing.

PRISM specifies controlled vocabularies of values for some elements. Others elements will use controlled vocabularies created and maintained by third parties, such as the International Standards Organization (ISO). Site-specific controlled vocabularies, such as from employee or customer databases, may also be used at the risk of limiting interoperability.

As another example, we can denote the location shown in the photograph by using the ISO country codes vocabulary:

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust/content/2357845" />

...

<dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR" />

</rdf:Description>

Definition of Controlled Vocabularies

PRISM provides a small namespace of XML elements so that new controlled vocabularies can be defined. For example, Wanderlust might have prepared an exportable version of their employee database that contained entries like:

...

<pcv:Descriptor rdf:ID=”emp3845”>

<pcv:code>3845</pcv:code>

<pcv:label>John Peterson</pcv:label>

<hr:hireDate>1995-2-22</hr:hireDate>

<hr:division>Photography</hr:division>

<hr:manager rdf:resource=”emp2234”/>

</pcv:Descriptor>

<pcv:Descriptor rdf:ID=”emp4541”>

<pcv:code>4541</pcv:code>

<pcv:label>Sally Smith</pcv:label>

<hr:hireDate>1999-12-02</hr:hireDate>

<hr:division>Photography</hr:division>

<hr:manager rdf:resource=”emp3845”/>

</pcv:Descriptor>

...

These entries use elements from the Prism Controlled Vocabulary (PCV) namespace for information important to the controlled vocabulary nature of the entries – the employee name and the employee ID. The PCV namespace also includes other elements so it can represent basic hierarchical taxonomies. The PCV namespace is not intended to be a complete namespace for the development, representation, and maintenance of taxonomies and other forms of controlled vocabularies. Other vocabularies, such as XTM or VocML, may be used for such purposes. As long as URI references can be used to refer to the terms defined in these other markup languages, there is no problem is using them in PRISM descriptions.

The sample descriptions above also mix in elements from a hypothetical Human Resources (hr) namespace. Providing that information enables useful functions, such as sorting the results by division or by manager, etc. The hr namespace is only an example, provided to show how elements from other namespaces may be mixed into PRISM descriptions.

Internal Description of Controlled Vocabularies

Linking to externally-defined controlled vocabularies is a very useful capability, as indicated by the range of additional views described in the earlier example. However, external vocabularies do require lookups in order to fetch that information, which may make common operations too slow. PRISM also allows portions of a vocabulary entry to be provided within a description that uses them, similar to a caching mechanism. For example, the PRISM description of the Corfu photo can be made more readable, while still allowing all the power that comes from controlled vocabularies, by providing some of the information inline:

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xml:base=”http://wanderlust.com/”>

<rdf:Description rdf:about="/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="/content/2357845" />

<dc:creator>

<pcv:Descriptor rdf:about="/emp3845">

<pcv:label>John Peterson</pcv:label>

</pcv:Descriptor>

</dc:creator>

<dc:coverage>

<pcv:Descriptor

rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">

<pcv:label xml:lang="en">Greece</pcv:label>

<pcv:label xml:lang="fr">Grece</pcv:label>

</pcv:Descriptor>

</dc:coverage>

</rdf:Description>

</rdf:RDF>

This approach uses the pcv:Descriptor element, which is a subclassof rdf:Descriptor, indicating that the resource is a taxon in a controlled vocabulary. Notice it also uses the rdf:about attribute, instead of the rdf:ID attribute, which means that we are describing the taxon, not defining it. The actual definitions of those terms are maintained elsewhere.

Relations

It is often necessary to describe how a number of resources are related. For example, an image can be part of a magazine article. PRISM defines a number of elements to express relations between resources, so describing that this image is part of a magazine article can be done as follows:

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845" />

...

<prism:isPartOf rdf:resource=

”http://wanderlust.com/2000/08/CorfuArticle.xml” />

</rdf:Description>

It is possible, but not mandatory, to add a statement to the description of the Corfu article saying that it contained the image:

<rdf:Description rdf:about="http://wanderlust.com/2000/08/CorfuArticle.xml">

...

<prism:hasPart rdf:resource=”http://wanderlust.com/2000/08/Corfu.jpg” />

</rdf:Description>

Resource Type and Category

Many different kinds of information are frequently lumped together as information about the 'type' of a resource. The PRISM specification breaks out three components:

First, file formats are indicated through the use of Internet Media Types (aka MIME types [RFC-2046]) in the dc:format element.

Second, information on the stereotypical type of intellectual content, such as obituaries vs. election results, is indicated through the use of the prism:category element and the controlled vocabulary presented in Table 17: Categories (intellectual genre).

The PRISM group found that these two were not all the types commonly used. Many ‘types’ commonly used, such as tables, charts, sidebars, etc. are not intellectual genre, they are stereotypical modes of presentation. As an example, election results could be presented in a table, a map, or many other ways. The type of presentation used in a resource is indicated by the dc:type element and the values listed in Table 16: Controlled Vocabulary of Presentation Styles.

For example, consider three different images – a JPEG photograph of a landscape, a PNG image of a political cartoon, and a PNG image of a graph from a financial statement. Table 1: Sample of Image ‘Types’ shows how those facts would be recorded in PRISM descriptions. Distinguishing these various facets will be helpful in advanced searching applications.

Table 1: Sample of Image ‘Types’

	dc:format	dc:type	prism:category
Image 1	image/jpg	Photo	n.a.
Image 2	image/png	illustration	cartoon
Image 3	image/png	Graph	financialStatement

Rights and Permissions

Licensing content for reuse is a major source of revenue for many publishers. Conforming to licensing agreements is a major cost – not only to the licensee of the content but also to the licensor. For these reasons, PRISM provides elements and controlled vocabularies for the purpose of describing the rights and permissions granted to the receiver of content. The PRISM specification provides those elements in two namespaces. Basic, commonly used, elements are defined as part of the PRISM namespace. A separate namespace is defined for the elements in the PRISM Rights Language (PRL). Since the field of Digital Rights Management (DRM) is evolving so quickly, the working group decided it would be premature to select one of the current XML standards for rights information, such as the eXtensible rights Markup Language [XrML] or Open Digital Rights Language [ODRL]. The working group expects that a rights management language will eventually become an accepted standard. It focused on specifying a small set of elements that would encode the most common rights information to serve as an interim measure for interoperable exchange of rights information.

To do this, the PRISM rights language makes a couple of simplifying assumption. It assumes that the sender and receiver of content are engaged in a business relation. It may be a formal contract or an informal provision of freely redistributable content. One of the parties may not know the other. Nevertheless, a relation exists and if needed we could make up an identifier for it. PRL also assumes that its purpose is to reduce the costs of conformance to that relation. The working group explicitly rejected imposing any requirements on enforcing trusted commerce between unknown parties. Instead, the emphasis is on reducing the cost of compliance in common situations.

No Rights Information

In the example below, no rights information is provided for the Corfu photograph. Does the lack of explicit restrictions mean the sender gives the receiver permission to do everything with the image? Or does the lack of explicitly granted rights imply that they can do nothing? Neither. Instead, we rely on the assumption of an existing business relation. In the absence of specific information, parties in a PRISM transaction assume that the normal rules of their specific business relation apply.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845" />

<dc:description>Photograph taken at 6:00 am on Corfu with two models

</dc:description>

<dc:title>Walking on the Beach in Corfu</dc:title>

<dc:creator>John Peterson</dc:creator>

<dc:contributor>Sally Smith, lighting</dc:contributor>

<dc:format>image/jpeg</dc:format>

</rdf:Description>

</rdf:RDF>

Basic Rights Information

While descriptions without any explicit rights information are possible, the working group decided there were some fields that were likely to be very commonly used. Those are provided in the PRISM namespace. The example below provides a copyright statementand contact information for the agency representing Wanderlust if someone wants to license the image for reuse.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource=" http://wanderlust.com/content/2357845" />

rights reserved.</prism:copyright>

<prism:rightsAgent>Phantasy Photos, Philadelphia</prism:rightsAgent>

</rdf:Description>

</rdf:RDF>

Specific Rights Information

PRISM also allows more specific information about the rights that the sender is granting to the receiver. This is a very important change in the nature of the metadata being provided. Up to now, all the metadata has been descriptive of the resource, independent of the receiver. Specific rights information, however, can only be given in the context of a particular agreement between the sender and receiver. As an example, the stock photo agency representing Wanderlust may have negotiated a contract with a licensor of the image. They could then send the image, accompanied by a description that specifically identifies that contract:

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:rights rdf:resource=

“http://PhillyPhantasyPhotos.com/terms/Contract39283.doc”/>

</rdf:Description>

</rdf:RDF>

This specifically identifies the terms and conditions for reusing the image. That can make the process of manually tracking down rights and permissions a little easier since the contract number is known. It also lets software be written to enforce the terms of particular contracts.

The prospect of implementing software to enforce the terms of each contract is not enticing. So, PRISM provides some simple mechanisms to accommodate common cases without specialized software. One common case is when a publisher provides a large amount of material, such as the layouts for an entire magazine issue, to a partner publisher who will republish parts of it. Much of the content in the issue will be the property of the sending publisher, and covered under their business agreement with the receiving publisher. However, the issue will also contain stock photos and other materials that are not covered by the agreement. The example below shows how the controlled value #notReusable indicates to the receiver, travelmogo.com, that this item is not covered under their agreement with the sender, Wanderlust. This is, in fact, a benefit to Wanderlust. Travelmongo.com will not ask Wanderlust staff to search for contract terms on images Wanderlust does not own – a considerable cost saving. The <rightsAgency> element is provided so that the receiver of a contact item has someone to contact should they wish to obtain the rights to use the non-Wanderlust content.

The description below also shows how the descriptions for multiple objects can be packaged into a single PRISM file:

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource=" http://wanderlust.com/content/2357845" />

rights reserved.</prism:copyright>

<prism:rightsAgent>Phantasy Photos, Philadelphia</prism:rightsAgent>

</rdf:Description>

<rdf:Description rdf:about="http://SunsetSnaps.com/20456382927.jpg">

<dc:description>Sunset over Corfu</dc:description>

<dc:rights rdf:resource=

”http://prismstandard.org/vocabularies/1.0/rights.xml#notReusable”/>

<prism:rightsAgent>Sunset Snaps, New York</prism:rightsAgent>

</rdf:Description>

</rdf:RDF>

The interpretation of the dc:rights statement is that the image from Sunset Snaps is governed by a specific agreement. The URI reference of that agreement is:

http://prismstandard.org/vocabularies/1.0/rights.xml#notReusable.

That agreement, which all PRISM-compliant systems MUST recognize, simply means that there is no agreement to reuse the image. TravelMongo is, of course, free to work out an agreement with Sunset Snaps if they want to, but they do not need to ask Wanderlust about whether they can reuse the image.

Detailed Rights Information

Of course, content licensing deals are frequently more involved than an all-or-nothing arrangement. It is very common to restrict the uses by time, geography, intended use, and industry sector of use. More specialized restrictions are also possible, such as “may not be used on keychains”, but the PRISM Working Group decided there was no need to define a machine-operable way to encode such specialized restrictions.

The example below shows how Wanderlust, or their agent, might restrict the length of time that TravelMongo can use the Corfu photo.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845" />

<dc:rights rdf:parseType=”Resource”>

<prism:releaseTime>2001-02-01</prism:releaseTime>

<prism:expirationTime>2001-02-28</prism:expirationTime>

</dc:rights>

</rdf:Description>

</rdf:RDF>

In that example, the dc:rights element contains the elements that describe the rights and permissions. To decide which elements go inside a dc:rights element, consider if they are likely to change as a consequence of who the content is being licensed to. Copyright statements are not highly variable. Time restrictions are variable.

More complex rights agreements, with multiple clauses, can also be conveyed. The description below says that the Corfu image cannot be used in the Tobacco industry, can be used in the US anytime from now on, and can be used in Greece before the end of 2003. Those three clauses are captured in the three elements within the rdf:Bag element.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/"

xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/”

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://wanderlust.com/2000/08/Corfu.jpg">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845"/>

<dc:rights xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml">

<rdf:Bag>

<rdf:li rdf:parseType="Resource">

<prl:usage rdf:resource="#none"/>

<prl:industry rdf:resource=

"http://prismstandard.org/vocabs/SIC/0132"/>

</rdf:li>

<rdf:li rdf:parseType="Resource">

<prl:geography rdf:resource=

"http://prismstandard.org/vocabs/ISO-3166/US"/>

<prism:releaseTime>2001-01-01</prism:releaseTime>

</rdf:li>

<rdf:li rdf:parseType="Resource">

<prl:geography rdf:resource=

"http://prismstandard.org/vocabs/ISO-3166GR"/>

<prism:expirationTime>2003-12-31</prism:expirationTime>

</rdf:li>

</rdf:Bag>

</dc:rights>

</rdf:Description>

</rdf:RDF>

Extending the PRISM Rights Language

As mentioned earlier, PRL is deliberately small. It can be extended by defining new elements and vocabularies to express new restrictions. New usage values could also be developed, but that is expected to be exceedingly rare.

As an example, a stock image provider will have some very common usage restrictions, and some very obscure ones, that need to be applied to images they license. The most common restrictions (time, place, industry) are already covered, but two that are not covered in PRL are audience size and manipulations applied to the photograph. Our example image provider, Sunset Snaps, could define two new RDF property types (snap:audienceSize and snap:manipulations) to represent those common restrictions. They would also define vocabularies of values for the elements, such as #flip, #rotate, or #falseColor, for the snap:manipulations element. There are more obscure conditions that require human evaluation. Popular supermodels may have clauses in their contracts that prevent their images being used to advertise discount or close-out merchandise, or on inexpensive promotional items.

Sunset Snaps can define a number of clauses expressing these conditions and provide them, either by reference or in-line, as shown below.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/"

xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/”

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:snap=”http://sunsetsnaps.com/rights/”>

<rdf:Description rdf:about="http://sunsetsnaps.com/Zing/asdf0838484">

<dc:identifier rdf:resource="http://wanderlust.com/content/2357845"/>

<dc:rights xml:base="http://sunsetsnaps.com/rights/">

<rdf:Bag>

<rdf:li rdf:parseType="Resource">

<prl:usage rdf:resource="#none"/>

<snaps:industry rdf:resource=”#flip”>

</rdf:li>

<rdf:li rdf:parseType="Resource">

<prl:usage rdf:resource="#none"/>

<snaps:industry rdf:resource=”#falseColor”>

</rdf:li>

<rdf:li rdf:parseType="Resource">

<prl:usage>Not to be used with discount merchandise.</prl:usage>

</rdf:li>

</rdf:Bag>

</dc:rights>

</rdf:Description>

</rdf:RDF>

Elements by Functional Group

This section provides summary tables of the elements specified by the PRISM working group, organized by the purpose(s) for which they are intended. This is intended to be a handy reference. The full, normative, definition of the elements appears in Section 5 “Element Definitions”.

General Purpose Elements

These elements from the Dublin Core form the basis for PRISM’s descriptive metadata. Many descriptions will need only a few elements from this table.

Table 2: General Purpose Descriptive Elements

Element	Role
dc:identifier	Identifier(s) for the resource.
dc:title	The name by which the resource is known.
dc:creator	The primary creator(s) of the intellectual content of the resource.
dc:contributor	Additional contributors to the creation or publication of the resource.
dc:language	The principal language of the resource.
dc:description	A description of the resource.
dc:format	The file format of the resource. Values from the Internet Media Types are recommended.
dc:type	The style of presentation of the resource’s content, such as image vs. sidebar.
prism:category	The genre of the resource, such as election results vs. biographies.

Provenance

These elements describe the supply chain for a resource to indicate what the source material for a resource was and through which organizations the resource has passed. PRISM uses the dc:source property to identify the original basis for the resource, the dc:publisher property to identify the primary provider of the information (such as a major wire service), and the prism:distributor property to identify other members of the distribution chain, if any.

Table 3: Elements for Provenance Information

Element	Role
dc:publisher	An identifier for the supplier of the resource.
prism:distributor	An identifier for the distributor of the resource.
dc:source	An identifier for source material for the resource.

Timestamps

There are several times that mark the major milestones in the life of a news resource: The time the story is published, the time it may be released (if not immediately), the time it is received by a customer, and the time that the story expires (if any). Dates and times should be represented using the W3C-defined profile of ISO 8601 [W3C-NOTE-datetime].

Table 4: Elements for Time and Date Information

Element	Role
prism:creationTime	Date and time the identified resource was first created.
prism:expirationTime	Date and time when the right to publish material expires.
prism:modificationTime	Date and time the resource was last modified.
prism:publicationTime	Date and time when the resource is released to the public.
prism:releaseTime	Earliest date and time when the resource may be distributed.
prism:receptionTime	Date and time when the resource was received on current system.

Subject Description

These elements describe the subject matter of a resource. Experience has shown that there are many different kinds of subjects. People, places, things, events, … are all possible subcategories of ‘subject’. Best practice is for subject description elements to reference controlled vocabulary terms such as the IPTC Subject Reference System. If that is not possible, dc:subject can also contain a prose description of the subject.

Table 5: Elements for Describing the Subject of a Resource

Element	Role
dc:coverage	Indicates geographic locations or periods of time that are subjects of the resource. For example, “20th Century”. The prism:location element is preferred for geographic subjects.
dc:subject	The subject of the resource.
dc:description	Prose description of the content of the resource.
prism:event	An event referred to in or described by the resource.
prism:industry	An industry referred to in or described by the resource.
prism:location	A location referred to in or described by the resource.
prism:person	A person referred to in or described by the resource.
prism:organization	An organization referred to in or described by the resource.

Resource Relationships

Published content has a wide variety of relations to other content items. There are containment relations – such as article containing a photo, story text and caption. There are version relations – such as a resource being a corrected version of another resource. There are alternative formats – such as a Word document also existing in HTML, XML and PDF. There are alternatives – such as an image that cannot be reused having alternatives that can. Many other types of relations exist. Many of the relations provided come from work undertaken by the Dublin Core Metadata Initiative and documented in the Relations Working Draft [DCMI-R].

Table 6: Elements to Convey Relations Between Resources

Element	Role
prism:isPartOf	The described resource is a physical or logical part of the referenced resource.
prism:hasPart	The described resource includes the referenced resource either physically or logically.
prism:isVersionOf	The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.
prism:hasVersion	The described resource has a version, edition, or adaptation, namely, the referenced resource. Changes in version imply substantive changes in content rather than differences in format.
prism:isFormatOf	The described resource is the same intellectual content of the referenced resource, but presented in another format.
prism:hasFormat	The described resource pre-existed the referenced resource, which is essentially the same intellectual content presented in another format.
prism:references	The described resource references, cites, disputes, or otherwise points to the referenced resource to acknowledge intellectual precedence.
prism:isReferencedBy	The described resource is referenced, cited, or otherwise pointed to by the referenced resource.
prism:isBasedOn	The described resource is a performance, production, derivation, translation, adaptation or interpretation of the referenced resource.
prism:isBasisFor	The described resource has a performance, production, derivation, translation, adaptation or interpretation, namely the referenced resource.
prism:isTranslationOf	The described resource is a human-language translation of the referenced resource.
prism:hasTranslation	The described resource has been translated into an alternative human-language. The translated version is the referenced resource.
prism:requires	The described resource requires the referenced resource to support its function, delivery, or coherence of content.
prism:isRequiredBy	The described resource is required by the referenced resource, either physically or logically.
prism:isAlternativeFor	The described resource can be substituted for the referenced resource.
prism:hasAlternative	The described resource has an alternative version that can be substituted, namely the referenced resource.
prism:isCorrectionOf	The described resource is a corrected version of the referenced resource.
prism:hasCorrection	The described resource has a correction, namely the referenced resource.

Rights and Permissions

The PRISM rights and permissions vocabulary is designed to facilitate reuse and clearance processes for parties with established business relationships by explicitly specifying the rights and/or restrictions connected with a resource. PRISM is NOT concerned with digital rights enforcement. PRISM does not specify policy or provide instructions to trusted viewers and repositories on how they should behave. PRISM also does not specify fee or payment details. Other efforts, such as XrML, are attempting to meet those needs, although there are no widely adopted solutions at this time.

The design goals of rights and permissions are:

To be able to describe reuse rights in a precise and consistent manner.

To make simple cases such as no rights or unrestricted use simple to specify

To provide the capability to indicate common types of uses or restriction.

To allow for graceful evolution to future accepted standards for specifying rights.

It is important to note that rights and permissions metadata is usually intended for a particular receiver, unlike elements such as “title” which are expected to be almost invariant.

Table 7: Elements for Specifying Rights and Permissions Information

Term	Role
dc:rights	Container element for specific rights data
prism:copyright	A copyright statement for this resource.
prism:expirationTime	Time at which the right to reuse expires.
prism:releaseTime	Time as which the right to reuse a resource begins, and the resource may be published.
prism:rightsAgent	Name, and possibly contact information, for the agencyto contact to determine reuse conditions if none specified in the description are applicable.
prl:geography	Specifies geographic restrictions.
prl:industry	Specifies restrictions on the industry in which the resource may be reused.
prl:usage	Specifies ways that the resource may be reused.

Note that in addition to the elements summarized in the table above, the PRISM Rights Language uses a small controlled vocabulary to provide well-known values for the prl:usage element. The values in it are:

Table 8: Predefined Usages

Term	Definition
#none	No use can be made of the resource under the specified conditions.
#use	The resource can be used under the specified conditions. The limits on the use of the resource are not further specified in the PRISM description and the relevant licensing agreement must be consulted.
#notApplicable	The conditions on use are not applicable to the current state of the system and the intended use(s) of the resource.
#permissionsUnknown	It is not known whether the resource may be used. Proceed at own risk.

Controlled Vocabularies

Many elements in PRISM-approved or PRISM-extended namespaces take values that are intended to come from controlled vocabularies. Controlled vocabularies are lists of terms that are updated through a defined and managed procedure. More formally, then entries in a vocabulary are known as taxons, since there may be more than one term used for that entry in the vocabulary. For example, “Greece” in English and “Grece” in French are two terms for the same taxon.

The list of taxons may be hierarchically structured subject classification systems like the Dewey Decimal Classification, or they may be simple lists of names of companies, people, places, etc. The vocabulary may come from an external source, or be derived from internal sources such as a company's database systems.

The PRISM specification provides a separate namespace of RDF Property Types for describing taxons in a controlled vocabulary. That namespace is the PRISM Controlled Vocabulary (PCV) namespace. Information about the taxon beyond that provided in the PCV namespace can be handled through the normal extension mechanism of new Property Types.

Table 9: Elements for Defining and Describing Controlled Vocabulary Entries

Element	Role
pcv:broaderTerm	Links to a broader (more general) concept in a vocabulary. For example, from the taxon for 'Dog' to the taxon for 'Mammal'. Multiple broaderTerm links are allowed.
pcv:code	Provides the unique identifier for the term.
pcv:definition	Provides a human-readable definition for the item in the vocabulary. Multiple definitions can be provided with different xml:lang attributes.
Pcv:Descriptor	Grouping element for the information describing or defining a taxon. The definition of a taxon MUST include a unique URI reference so that the taxon can be unambiguously identified.
pcv:label	Provides a human-readable label for the preferred name(s) of the taxon. Multiple labels can be provided, usually with different xml:lang attributes.
pcv:narrowerTerm	Links to a narrower (more specific) concept in the vocabulary. For example, from the taxon 'Dog' to the taxon 'Dalmatian'. Multiple narrowerTerm links are allowed.
pcv:relatedTerm	Links to a 'related term' in the vocabulary, where the nature of the relation is not specified.
pcv:synonym	Provides alternate human-readable labels (synonyms) for the same property.
pcv:vocabulary	Provides a human-readable string identifying the vocabulary from which the term comes.

PRISM In-line Markup

Important information, such as dates and the names of people, places, and things, occurs in the text of an article. Some organizations prefer to mark that data in-line rather than create a large set of subject description elements. PRISM provides the following elements for inline markup. These can be mixed into DTDs that specify the allowed structure of the document.

Table 10: Elements for In-Line Markup of Named Entities

Element	Role
pim:location	Marks a geographical location.
pim:objectTitle	Marks the title of a book, film, painting, product, etc.
pim:organization	Marks the name of a government, department, company, charity, club, or any other organization.
pim:person	Marks the name of a person (real or imaginary).
pim:quote	Marks the words attributed to a specific person.

Note that some of these elements, pim:quote in particular, have several attributes that provide additional information.

Part II: Normative Specification

Framework

Requirement Wording Note

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. The PRISM specification also uses the normative term, “STRONGLY ENCOURAGES,” which should be understood as a requirement equivalent to MUST in all but the most extraordinary circumstances.

Capitalization is significant; lower-case uses of the key words are intended to be interpreted in their normal, informal, English language way.

Behavior of PRISM-compliant Software

The PRISM specification defines the format of XML content exchanged between systems. It constrains the behavior of those systems as little as possible.

Discarding metadata is discouraged but not forbidden. A major cost occurs when metadata has to be recreated after it was discarded earlier in the production process. Therefore implementations MAY retain and retransmit any information that they do not know is actually wrong.

Novel elements and attributes MAY be added to PRISM descriptions. PRISM-compliant software MUST be capable of detecting such novel elements and attributes. It MUST NOT throw an error when a novel element is encountered. The PRISM working group recommends, in keeping with the recommendation above, that implementations MAY retain the novel information and pass it along.

Novel elements and attributes MUST NOT be added to PRISM namespaces and vocabularies or the Dublin Core namespace. One or more new XML namespaces MUST be defined for novel elements and attributes.

Identifying PRISM Content

The Internet Media Type (aka MIME type)[IETF-MIMETYPES] for PRISM descriptions is“application/prism+rdf+xml”. When PRISM descriptions are stored as XML files, the preferred filename extension is “.prism”. When neither of those two identification methods are appropriate, the content can be scanned for occurances of the URI ”http://prismstandard.org/namespaces/1.0/basic/” used as a namespace URI in an XML documents. Such documents are considered to be PRISM content.

Namespace and Vocabulary Identifiers

Systems that implement this specification MUST recognize and support at least the first four namespaces in the table below. Systems offering inline markup MUST support the fifth. Systems supporting the more expressive rights language MUST support the sixth. Systems MAY use the namespace declarations below in order to use familiar prefixes.

Table 11: Namespaces Used In PRISM Descriptions

Namespace	Recommended Namespace Declaration
Resource Description Framework	xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
Dublin Core	xmlns:dc=”http://purl.org/dc/elements/1.1/”
PRISM	xmlns:prism=”http://prismstandard.org/namespaces/1.0/basic/”
PRISM Controlled Vocabulary	xmlns:pcv=”http://prismstandard.org/namespaces/1.0/pcv/”
PRISM Inline Markup	xmlns:pim=”http://prismstandard.org/namespaces/1.0/pim/”
PRISM Rights Language	xmlns:prl=”http://prismstandard.org/namespaces/1.0/prl/”

The PRISM specification also defines a number of controlled vocabularies. The base URIs for those vocabularies are:

Table 12: Base URIs for PRISM Controlled Vocabularies

Vocabulary Name	Base URI
Content Categories (genres)	http://prismstandard.org/vocabularies/1.0/category.xml
Resource Types (presentation types)	http://prismstandard.org/vocabularies/1.0/resourcetype.xml
PRL Usage Types	http://prismstandard.org/vocabularies/1.0/usage.xml
PRISM Rights	http://prismstandard.org/vocabularies/1.0/rights.xml

All PRISM-compliant systems MUST recognize the #notReusable entry in the PRISM Rights vocabulary and handle it appropriately.

In addition to the PRISM-defined vocabularies, a number of other vocabularies and data formats are recommended by PRISM as current best practice. Those are:

Date-time

PRISM-compliant applications sending metadata to other systems are STRONGLY ENCOURAGED to use the W3C profile of ISO 8601 [W3C-DateTime] as the format of their date and time values. Implementers are advised, however, that this specification may be supplanted in the future by one which allows features such as ranges of times, or the use of the tz library’s method of specifying time zone offsets as strings composed of Continent/City. So implementations SHOULD be able to deal with other forms.

Locations

PRISM-compliant applications sending metadata to other systems are STRONGLY ENCOURAGED to use the codes from [ISO-3166] as the values for the <prism:location> and <prl:geography> elements.

ISO has not yet defined a standard URI convention for those codes. In order to maximize interoperability, implementations MAY wish to use the following non-resolvable URLs.

http://prismstandard.org/vocabs/ISO-3166/XX

where XX is a 2-letter uppercase country code, and

http://prismstandard.org/vocabs/ISO-3166-2/XX-YYY

where XX is as above and YYY is a one to three-character alphanumeric subregion code.

Industrial Sector

PRISM-compliant applications sending metadata to other systems MAY wish to use the industry sector codes from [NAICS] as the values for the <prism:industry> element and <pim:industry>’s href attribute.

Identifiers

PRISM files use therdf:about attribute on rdf:Description elements to specify the resource being described. The value of the rdf:about attribute MUST be a URI reference [RFC-2396]. The dc:identifier element MUST be used to contain any additional identifiers to be sent, or any identifiers that cannot be represented as a URI reference. For example, a resource can be identified by a URI and by an internal asset ID that an organization would use to access it in their database. PRISM-compliant applications are STRONLY ENCOURAGED to maintain the unique identifier(s) provided for a resource.

PRISM’s only policy on the assignment of identifiers is that the party assigning an identifier MUST NOT assign the same identifier to a different resource, using whatever definition of ‘different’ the assigning party deems appropriate.

PRISM systems MUST regard two resources as being ‘the same’ if they have the same unique identifier. The party assigning the identifier is the sole arbiter of what they mean by ‘the same’. Note that this definition does not imply that two resources are different if their identifiers are different. Different identifiers MAY (and frequently will) be assigned to the same resource.

PRISM does not require that all resources carry the same identifier through their entire lifecycle. However, if the publisher assigns a new identifier to non-reusable content obtained from an external party, the publisher SHOULD retain information on the origin and licensing of the resource so that someone later in its lifecycle can determine how to obtain the rights to reuse it.

Cardinality and Optionality

All PRISM descriptions MUST contain at least one identifier for the resource being described, expressed in the rdf:about attribute. Any number of additional identifiers MAY be expressed in dc:identifier elements. The identifier in the rdf:about attribute is the only mandatory field in a PRISM description. However, at least one other field MUST be specified in a description in order to have a meaningful model.

All Dublin Core elements are optional, and may be repeated any number of times. Unless specifically noted otherwise, PRISM elements are also optional and may occur any number of times in a description.

Automatic Creation of Inverse Relations

PRISM includes elements for specifying relations between resources (e.g. Resource1 isVersionOf Resource2). Those relations have inverse relations that are also in the PRISM specification (e.g., Resource2 hasVersionResource1).

PRISM-compliant systems which receive one side of such a relation MAY infer the presence of the additional inverse relation. To be more specific, if the implementation tracks the origin of individual RDF statements and can segregate its database in order to undo the addition of such inferred inverses, it SHOULD infer the inverse and keep it segregated from the original input. If an implementation does not track individual statements and sources, it MAY infer the inverse relations but is cautioned about the possibility of data corruption.

PRISM Profile of the Resource Description Framework

The Resource Description Framework (RDF) has been standardized by the W3C to provide a general framework for metadata. As such, its capabilities exceed those required by PRISM. Therefore, this document specifies a ‘profile’ – a restricted subset – of RDF that all PRISM-compliant software MUST support. This profile excludes certain capabilities of RDF that are not needed in PRISM applications, thus simplifying the development of PRISM applications.

Applications conforming to the PRISM specification MUST produce correct RDF documents that can be read by any RDF-compliant software. They MUST also produce documents that conform to the PRISM profile of RDF. PRISM-compliant software does not have to be capable of processing arbitrary RDF documents.

Constraint 1: Top-level structure of Descriptions

The formal grammar for RDF [W3C-RDF] specifies:

[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
[6.2] obj ::= description | container

For PRISM descriptions, the rdf:RDF wrapper element is required, and its child elements are restricted to being rdf:Description elements. The production that replaces productions 6.1 and 6.2 for PRISM systems is:

RDF::= '<rdf:RDF' namespace_decls '>' description+ '</rdf:RDF>'

Constraint 2: rdf:aboutEachPrefix disallowed

PRISM descriptions MUST NOT use the rdf:aboutEachPrefix attribute. Production [6.8] of the RDF M&S specification thus becomes:

AboutEachAttr::= ' aboutEach="' URI-reference '"'

Further Qualifications

No other overall restrictions in the allowed RDF syntax are specified in this section. However, implementers are advised to pay particular attention to the following points:

Many elements, such as dc:subject, may take a string as a value, or may use a URI for identifying an element in a controlled vocabulary of subject description codes. The URI may be a simple reference, or may provide an inline description of the controlled vocabulary term. Implementations MUST be capable of handling all three of those cases reliably.

Implementers must decide how their system will deal with unsupported descriptive elements. The PRISM specification does not preclude other descriptive elements, although their interoperation cannot be guaranteed. PRISM implementations MAY retain unknown descriptive elements and retransmit them.

To aid automated processing of PRISM metadata, this specification defines a separate namespace for PRISM elements suitable for in-line markup. Thus, prism:organization is an RDF statement and pim:organization is used as in-line markup.

The PRISM working group encourages implementers to keep the generated markup as simple as possible. As an example, if a work has multiple authors, RDF allows that situation to be encoded in two ways, which have slightly different meanings. The first way uses multiple dc:creator elements, each listing a separate author. The second way is to have a single dc:creator element, which then contains one of RDF’s collection constructs, such as rdf:Bag. That, in turn, would list the different authors. According to the RDF specification, the first is to be used when the authors acted as a collection of individuals in the creation of a work. The second is to be used when the authors acted as a committee. Experience has shown, however, that this distinction is too subtle for human catalogers to make reliably. The PRISM working group recommends using the first approach in most cases.

Note that although a sequence of dc:creator elements in an RDF/XML file implicitly defines a sequence (in the XML world), RDF parsers have no obligation to preserve that ordering, unlike if an explicit rdf:Seq were given. PRISM implementors are advised that there are quality of implementation issues between different RDF processors. In general, implementers MAY prefer to build on top of an RDF parser that allows the original order of the statements to be reconstructed. That would allow the original order of the authors on a piece to be reconstructed, which might or might not convey additional meaning to the viewer of a styled version of the record. Similarly, XML software that can handle the almost-standardized xml:base attribute MAY be preferred.

Conventions for Property Values

To aid in the automatic processing of PRISM documents, PRISM utilizes some conventions in expressing values of RDF properties. The values are expressed in three ways. First, a resource or an entry in a controlled vocabulary MAY be referenced with the rdf:resource attribute. For example, a book can be identified by its ISBN number as follows:

<dc:identifier rdf:resource=”urn:isbn:0-932592-00-7”/>

Second, human readable text MUST be is represented as element content:

<dc:title>Juggling for the Complete Klutz</dc:title>

barring any circumstances where representing the text in element content would change the RDF as compared to representing it as an attribute value. That element content may contain XML markup, in which case the rdf:parseType attribute MUST be given and MUST have a value of 'Literal'.

Third, controlled vocabulary entries may be specified in-line. For example:

<dc:subject>

<pcv:Descriptor rdf:about=”http://loc.gov/LC/QA-76”>

<pcv:vocabulary>Library of Congress Classification</pcv:vocabualry>

<pcv:code>QA-76</pcv:code>

<pcv:label>Mathematical software</pcv:label>

</pcv:Descriptor>

</dc:subject>

XML DTDs cannot describe such a flexible content model, so no DTD is provided in this specification.

Convention 1: In-line controlled vocabulary term definitions preferred

PRISM descriptions make extensive use of values selected from controlled vocabularies. Conceptually, all that is needed is a reference to the vocabulary entry. But for practical considerations such as human readability, ease of use of full-text search tools, and performance, it is useful to be able to provide information about the controlled vocabulary entry, such as its human-readable label, directly in the description.

The PRISM specification recommends that when this additional information is provided, that it be provided in-line, instead of as an additional rdf:Description element. For example, a story whose subject is "Mining" as defined in the North American Industrial Classification System (NAICS), would have the following description:

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="story.xml">

<dc:subject>

<pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/NAICS/21">

<pcv:vocab>North American Industrial Classification System</pcv:vocab>

<pcv:code>21</pcv:code>

<pcv:label>Mining</pcv:label>

</pcv:Descriptor>

</dc:subject>

</rdf:Description>

</rdf:RDF>

as opposed to the form of the description below, where the controlled vocabulary term is described out-of-line instead of in-line.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns:prism="http://prismstandard.org/1.0#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="story.xml">

<dc:subject rdf:resource="http://prismstandard.org/vocabs/NAICS/21"/>

</rdf:Description>

<pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/NAICS/21">

<pcv:vocab>North American Industrial Classification System</pcv:vocab>

<pcv:code>21</pcv:code>

<pcv:label>Mining</pcv:label>

</pcv:Descriptor>

</rdf:RDF>

The two approaches are identical in terms of the RDF graph that is generated, but the former is believed easier to deal with using standard tools such as full-text indexing software or simple editing scripts.

Note that we use the rdf:about attribute when providing the information on the controlled vocabulary term. This indicates that the real definition of the term is elsewhere, and we are merely providing some local descriptions of that term.

Element Definitions

The PRISM specification recommends existing elements (in the case of the Dublin Core) or defines new elements to use for descriptive metadata. The detailed, normative, definitions of those elements is provided in this section.

All the element definitions appear in a uniform format. Each element definition begins with two fields – the Name and the Identifier of the element. The Name is a human-readable string that can be translated into different languages. Also, note that PRISM does NOT require that users be presented with the same labels. The Identifier is a protocol element. It is an XML element type and MUST be given as shown, modulo the normal allowance for variations in the namespace prefix used.

XML Entities Used In Definitions

Some of the content models used in this section provide content models that use parameter entity references. Those parameter entities and their meaning are:

Table 13: Entities Used as Abbreviations in Element Definitions

Parameter Entity	Definition
%AuthorityReference;	An attribute, “rdf:resource”, whose value is a URI referring to a term in a controlled vocabulary.
%content.mix;	Typical mix of elements for representing content, such as #PCDATA, <p>, <bold>, <quote>, etc. The details of the parameter entity will depend on the context in which the PRISM namespace is being used. Note that PRISM very rarely specifies a pure #PCDATA content model, because of the need for BiDi and Rubi markup in internationalization situations.
%ResourceReference;	An attribute, “rdf:resource”, whose value is a URI reference to a resource. The set of AuthorityReferences is a subset of the set of ResourceReferences.
%TimeSpecification;	A string specifying a date and time according to the W3C profile of ISO 8601 (e.g., YYYY-MM-DDThh:mm:ss.ssTZD) [W3C-NOTE-datetime].

Dublin Core Namespace

The normative definitions of the Dublin Core elements can be found in [DCMI]. The following table adds comments to indicate the use of each Dublin Core element in a PRISM document. The use of some DC elements is encouraged, others are discouraged, and others constrained.

None of the Dublin Core elements are required to appear in a PRISM description, and all of them are repeatable any number of times.

dc:contributor

Name	Contributor
Identifier	dc:contributor
Definition	An entity responsible for making contributions to the content of the resource.
Comment	Examples of a Contributor include a person, an organization, or a service. Typically, the name of a Contributor should be used to indicate the entity.
Attributes	%AuthorityReference if empty.
Model	(%content.mix;) or EMPTY if %AuthorityReference is given.
Occurs In
Example	<dc:contributor>John Smith</dc:contributor> <dc:contributor rdf:resource=”http://wanderlust.com/jas”/>

dc:coverage

Name	Coverage
Identifier	dc:coverage
Definition	The spatial and/or temporal extent of the content of the resource.
Comment	Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to use prism:location for case

PRISM: Publishing Requirements for Industry Standard Metadata

Abstract

Status

Acknowledgements

Working Group Members (Current and former)

Part I: Introduction and Overview

eXtensible Rights Markup Language (XrML)

XTM (XML Topic Maps)

Structure of this Document

Overview

Travel Content SyndicationScenario

A Brief Digression on Identifiers

A Brief Digression on Intent

General Purpose Elements

Controlled Vocabularies

Date-time

Locations

Industrial Sector

Constraint 2: rdf:aboutEachPrefix disallowed

Element Definitions

dc:coverage