1.1 Audience

This specification details the nature of Z39.98 Authoring and Interchange Format (Z39.98-AI) profiles and how they are created. It is intended primarily for agencies interested in creating conformant profiles for new documents types and for processing agent developers.

This specification is not a guide to marking up Z39.98-AI documents and should not be referenced as such. Informative resources that describe Z39.98-AI document production are available independently of this specification.

Although this specification contains introductory sections where appropriate and deals with general document concepts in places, it is expected that all persons reading this specification will have a strong background in XML and its related technologies — in particular schema languages and their composition — in order to properly implement new profiles.

1.2 Design goals

The Z39.98-AI Framework has been built with the following primary design goals in mind:

1.3 Overview

Creating profiles that conform to this specification requires understanding how the various concepts and technologies outlined in this document are bound together to define information resources. Although some readers will be sufficiently comfortable with XML technologies to jump straight into the specification, this overview provides a quick reference guide to how profiles are constructed and where the requirements are defined for both novice and experienced developers alike.

At the core of the Z39.98-AI specification is the Abstract Document Model, which introduces the framework common across all profile implementations, and the high-level rules to which profile creators must adhere in order to ensure consistency and predictability between grammars. The Abstract Document Model is like a map to building profiles and its concepts are fully introduced in 4, Abstract Document Model.

Understanding the Abstract Document Model is essential to understanding the rest of the specification, as the process of creating profiles involves formalizing rules to enforce the abstract concepts, as illustrated in Figure 1:

 

Figure 1: Overview of the Z39.98-AI profile creation process

Profiles are the practical product of the Z39.98-AI specification and take the form of markup models defining the structure of information resources. The rules and requirements for creating them are detailed in 6, Profiles.

Profiles are built on a modular model, allowing component definitions to be reused across Z39.98-AI profiles and to be included from other industry-standard grammars. The following sections of the specification introduce the various parts in their construction:

RDF is the primary means provided by the Framework for the expression of metadata about documents and for the semantic inflection of meaning on elements they contain. Although profile creators may use other methods to annotate their data, the use of RDF vocabularies is encouraged because of their tight binding to the specification. Information on how to apply the available attributes and vocabularies can be found in 11, RDF vocabularies.

A completed profile will typically consist of a variety of different resources, such as schema files, RDF vocabularies, additional prose restrictions as well as usage and other documentation. The publishing of a profile is the act of assigning it an identity URI (see 6.3.1, Profile identity URI), at which location a resource directory document is available that enumerates these resources and provides additional information on how to obtain them. Complete information on how to create resource directories and documents is available in 10, Resource directories.

This specification also includes a catalog of profiles that have been made publicly available for use in creating documents (available in Appendix A, Profile, feature, and vocabulary catalogs). Producers are not required to use these profiles, but they have been designed for the widest use possible to encourage their adoption. The profiles represent fully-compliant implementations of this specification for developers or individuals looking for practical representations of the specification.

Although this specification is not specifically intended for document creators, it does contain information about the general nature of document creation, including how to specify the profile a document conforms to, any features in use, as well as required metadata that must be included to identify the document. This information can be found in 8, Documents.

This specification also includes a packaging format based on the Open Container Format [OCF], which may be used to bundle the XML, image, and other local resources that compose a Z39.98-AI document set. It also specifies a MIME type [RFC2046] for the container format to facilitate the interchange of these files. This information can be found in 9, Container and in Appendix C, Media type registration.

In addition to gaining a full understanding of all the topics outlined above, processing agent developers must also ensure that their applications meet the conformance requirements detailed in 12.2, Processing agent conformance definition.

1.4 Relationship to other specifications

1.5 Conformance statements

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

The normative and informative appendices to this specification are identified by the labels “(normative)” and “(informative)” in their titles, respectively.

All examples in this specification are informative.

4.1 Introduction

The Abstract Document Model underpins the Z39.98-AI specification, providing the base structure through which all document profiles are defined. It is both a concept for defining the structure of documents and a model for creating valid Z39.98-AI profiles: the central concept of the model being that documents can be decomposed to a common foundation and that functionality can be built up in distinct layers.

Four such layers of increasing structural markup granularity are defined to cover the major components of a document: a general section layer for the hierarchical structure, a block layer for container elements, a layer for phrase constructs and finally the layer containing the text data of the document. The Abstract Document Model does not just define element structure, however; it additionally defines two complementary collections of attributes that flow through the element layers (the global and metadata attribute collections). It also exposes all of these layers and collections for customization and extension, which is where its flexibility for representing new document types lies.

Figure 2 provides a visual perspective of how the layers work in a bounding box-like fashion.

 

Figure 2: The document foundation and four layers of the Abstract Document Model

The layers of the Abstract Document Model are also how the model moves from abstraction of a document into formalization of the concept; they are more than just a way of conceiving of a document, but also represent the practical implementation of each profile through schema classes. Profile creators must not change the document foundation, or remove layers nor their inherent traits. The ability to create new profiles to describe information resources lies in the freedom offered within each layer to include elements and attributes to create new markup models. As a result, the Abstract Document Model can be used to create schematic definitions for documents across a wide spectrum of formats and fields while ensuring a predictable core structure.

The Z39.98-AI specification was built on this model specifically to address the problem of extensibility that existed in earlier versions of the Z39.86 standard. No single schema can encompass all document types and provide all the structure and flexibility necessary to generate all accessible formats. Although extension points were introduced in previous versions of Z39.86 to try and address this problem, they only allowed authors fixed entry points into a fixed model; the ability to fully recompose a schema to accommodate a new form was lacking.

The Abstract Document Model instead provides a common framework and over-arching set of rules in which profiles can be built without imposing unnecessary production and semantic restrictions. With the ability to insert new components at each layer, and at the same time leverage the components available in the core modules and from external features, the Z39.98-AI specification unshackles production from the monolithic approach of pre-defined and rigid markup models.

4.2 Fundamentals

                        
<document xmlns="http://www.daisy.org/ns/z3998/authoring/">
  <head>
    …
  </head>
  <body>
    …
  </body>
</document>

<body>
    <section>
        <block>
            <phrase>text</phrase> text <phrase>text</phrase>.
        </block>
        <block>
            …
        </block>
        <section>
            …
        </section>
    </section>
</body>

                        
<section about="origin_of_species">
    <h property="dc:title">On the Origin of Species by Means of Natural Selection</h>
    <p property="dc:creator">Charles Darwin</p>
</section>

                        
<section xml:id="s1">
    <p xml:id="p1">
         <w xml:id="w1">…</w> 
    </p>
</section>

4.3 Layer and Collection Definitions

5.1 Introduction

Modules are the high-level building blocks of Z39.98-AI profiles and together with features form the basis through which new markup models are created. Modules may be pre-defined (as in the case of the core modules), may be composed by profile authors to fit specific structural needs or may be made available for public use by interest groups.

Modules, in their practical form, are schema files that define custom components — such as elements and attributes — for use in building profiles. The components within any module typically share a common nature or serve a common structural purpose, allowing the targeted activation of modules for specific uses. This approach to module definition enables element and attribute counts to be kept to a minimum when composing new grammars.

5.2 Module and component definitions

Module and component definitions are informational resources that define the nature of a given module and its components. These definitions provide the default state of modules and components prior to activation, as well as high-level instruction on their proper use.

A definition must contain the module name, its dependencies and a description of its purpose. Each component defined in the module must also be listed along with usage information, as outlined in 5.3, Components. Core modules additionally specify whether the module is required to be activated in all Z39.98-AI compliant profiles.

There are no rules on the format and structure of a definition resource. So long as complete information about the nature and traits of each module and component is made available in human readable form, the requirement to provide a definition has been satisfied.

Definitions must be provided for all module components created specifically for use in the Z39.98-AI Framework, and each profile’s resource directory must indicate the location of these definitions. Core module definitions are available at http://www.daisy.org/z3998/2012/auth/cm/.

Definitions for imported features are recommended but are not a requirement, as the official documentation maintained by the authoring body should be referenced instead.

Note that module and component definitions are not a reference to how to mark up a document to conform to a specific profile and should never be consulted to resolve validation issues. The normative schema available in the profile’s resource directory is the authoritative reference to creating valid documents.

5.3 Components

5.4 Expression

A module is formally expressed using one or more normative schemas authored in any of the languages specified in Appendix B, Schema languages.

5.5 Activation

Activation of a module is the process of importing it into a Z39.98-AI profile and including its components in content models and class definitions The first step in the activation process is to import the desired module into a profile driver file. If the module lists other modules as dependencies, those modules must also be imported, including any of their dependencies. This process of importing module dependencies continues until all required modules have been included. (Note that each dependency only needs to be imported once.)

Modules may have both hard dependencies, where failing to import a dependent module will result in a schema error, and soft dependencies, where no errors are reported. Omitting a soft dependency, while not resulting in an error in the schema file, still results in an invalid Z39.98-AI profile.

The next step in the activation process involves addressing the usage requirements for each component in the module, namely:

Module files should not be directly edited to make modifications; any changes should be made in the profile driver file where the module is included. Example 5 shows how a definition can be overridden when activating a module.

<include href="./mod/z3998-document.rng">
  <!-- redefine body content to use partitions -->
  <define name="z3998.body.content">
     <ref name="z3998.partitions"/>
  </define>     
</include>

Altering the components of a module is not required, and in some cases may not be permitted. If a module is fixed and not alterable, or if all of its components are to be used in their default state, the activation process may end with the import of the module.

The activation process must be carried out for all the required modules, optional modules and features needed to fully represent the new Z39.98-AI profile.

5.6 Core modules

The core modules were developed to accompany this specification to assist in the creation of new profiles. Some of the modules are required to be activated in all compliant profiles, as they define the document foundation and other core aspects of the Abstract Document Model, while the other optional modules provide a common base of components to encourage structural consistency across profiles.

The modules are grouped so that each contains a single set of semantically and/or structurally related elements and attributes. The definition for each module can be found in the ANSI/NISO Z39.98-2012 — Core Modules document that accompanies this specification. Profile creators should always check these definitions for compatible components before constructing a new module.

Core modules must not be directly modified to alter their component definitions. If module components allow modifications to any of their traits, those modifications must be made in the profile driver file during activation.

Profile creators are advised not to reference the publicly available versions of the core modules in their profile driver files, as the public location always contains the latest releases. The core modules are subject to change independent of this specification, so local copies of the modules should always be referenced to ensure the stability of any profile.

6.1 Introduction

A profile is the collection of resources that together define the rules and requirements for marking up an information resource. Profiles are typically equated with XML schemas, but a schema may be only one of a number of resources that define the requirements: the prose definition that accompanies each module may outline implicit attribute values that must be recognized when an attribute is not present, for example, and an RDF vocabulary may define a set of allowed role values for adding semantic information to elements. It is also not uncommon that more than one schema may define the markup requirements: a RelaxNG schema to express the general structure of a document and a Schematron schema to express finer-grained conformance logic.

Where the Abstract Document Model defines Z39.98-AI document structure at a conceptual level and, coupled with the core modules, provides a common framework of composition rules and abstract building blocks, profiles define the practical markup models suitable for describing information resources. Examples of the types of resources that can be defined using the Framework include:

This specification does not place any restrictions on the scope of profiles: depending on their intended use, profiles may have a wide scope (such as a general book profile) or they may have a narrow scope (such as a consumer medical information profile).

6.2 Creation

The process of creating a profile typically begins with the authoring of a schema to represent the desired information resource(s). The Z39.98-AI Framework encourages a plug-in model for creating schemas, whereby existing modules and features are re-used so that only the specialized requirements of the profile result in new elements and attributes.

A thorough understanding of the requirements of this specification will be necessary to successfully create a new schema. Compliance with the Abstract Document Model, for example, requires that all profiles must first include the document module in their schema driver file (the schema file that will be referenced by validators) to establish the root document element. The global-classes module must then be imported to establish the Abstract Document Model classes into which all other module and feature components will be added.

This process of dependency and required component inclusion continues until a complete markup model is established that conforms to the requirements outlined in 6.3.2, Profile markup model definition (see also 5.5, Activation for more information on the inclusion process). It is also during this process that other external resources, such as RDF vocabularies, will be identified and incorporated into the profile.

The next step in creating a profile is to determine whether, in fact, a new unique profile has been created. The uniqueness of a profile is not determined solely by the modules and features that it includes, however; it is possible for many unique profiles to be created using the same core modules. The actual distinction between profiles is determined by variations across all of the following key factors:

When the new profile is ready for use, a resource directory must be published at the schema’s identity URI (see 6.3.1, Profile identity URI). This document identifies the schema files, RDF vocabularies, documentation, and other associated resources in a manner that allows humans and machines to locate them.

If a profile is being created to serve only a unique subset of a larger existing profile (or to provide a localization), the documentation that accompanies it should clearly identify its parent model as well as where it varies to assist processing agent developers.

The Z39.98-AI Working Group developed a set of profiles that conform to this specification. References to these profiles can be found in A.1, Profile catalog. While the intent is that this profile catalog will be extended over time, the profiles listed in the catalog are not an exclusive set; other agencies may create profiles and, if desired, make those available independently for public use.

6.3 Profile conformance definition

7.1 Introduction

Certain kinds of content structures have highly specialized requirements for representation and processing, but have limited scope within information resources. A typical example is mathematical equations, where there already exists a specialized markup to represent them [MathML]. Z39.98-AI features are designed to handle these kinds of structures.

Features have much in common with profiles: each feature defines a markup model and has a unique URI associated with it that serves as its identifier, and that resolves to a unique resource directory. Features are more specialized, however, and narrower in scope; they are not intended to be used as complete markup languages on their own. In the Z39.98-AI framework, features may be optional add-ons to profiles.

Features typically only expose a small set of elements and attributes for reference within the content models defined by profiles. These components are defined by the feature in its associated normative prose in order to ensure consistency of usage across Z39.98-AI profiles. The predictability of features further allows processing agents to support them independently of the profiles that might reference them.

Profiles explicitly declare which (if any) features they support. If a profile supports a feature, it becomes a “host” of this feature, and the profile’s normative schema includes the schema fragment defined by the feature.

7.2 Feature conformance definition

8.1 Introduction

The purpose of authoring Z39.98-AI profiles is ultimately to allow the creation of documents that represent information resources. A Z39.98-AI document is a well-formed XML document that conforms to all the normative constraints defined by a profile and any included features.

Although Z39.98-AI documents may exist as single XML files that reference no additional local or remote resources, a complete Z39.98-AI document set typically will include local resources (such as included XML fragments, images, style sheets and metadata records), as well as reference remote resources that can be obtained by their protocol (web-hosted resources available over HTTP or FTP, for example). To simplify the distribution of documents, the Z39.98-AI Framework consequently also defines a container format specification for the bundling of local resources with their associated Z39.98-AI document.

8.2 Document conformance definition

In order to be conformant, a Z39.98-AI document must meet all of the following criteria:

8.3 Referencing profiles and features

Documents must reference the profile to which they adhere via a meta element in the metadata container element (see 4.3.2, Document foundation). The profile’s identity URI must be given in the resource attribute and the value of the rel attribute must contain the term profile (as defined in the Z39.98-2012 Instance Metadata Vocabulary). The unique name and version number of the profile must also be identified using the name and version properties.

Each feature used in the document must also be referenced via a meta element in the metadata container. In referencing features, the rel attribute must contain the term feature (as defined in the Z39.98-2012 Instance Metadata Vocabulary). Each feature similarly must reference its unique name and version number.

Example 6 illustrates a compliant profile and feature reference in the head element of a Z39.98-AI document.

                    
…
<head>
  <meta rel="z3998:profile" resource="http://example.org/z3998/2012/auth/profiles/sciencejournal/1.0/">
    <meta property="z3998:name" content="sciencejournal" />
    <meta property="z3998:version" content="1.0" />
    
    <meta rel="z3998:feature" resource="http://example.org/z3998/2012/auth/features/physics/3.0/">
      <meta property="name" content="physics" />
      <meta property="version" content="3.0" />
    </meta>
    
    <meta rel="z3998:feature" resource="http://example.org/z3998/2012/auth/features/chemistry/1.1/">
      <meta property="name" content="chemistry" />
      <meta property="version" content="1.1" />
    </meta>
  </meta>
</head>
…

Note that in Example 6, the feature reference meta elements are nested within the profile reference meta element. This is not a conformance criterion. The order in which the references appear, and whether or not they are nested within each other, is not significant.

8.4 Referencing RDF vocabularies

Documents must include a meta element in the document head that references the URI of their initial context document, as illustrated in Example 7.

                    
<document xmlns="http://www.daisy.org/ns/z3998/authoring/" xml:lang="en">
  <head>
    <meta rel="z3998:rdfa-context" resource="http://www.daisy.org/z3998/2012/vocab/context/default/" />
  </head>
  …
</document>

The referenced context document may define a default vocabulary, which allows the terms from that vocabulary to be added in their unprefixed form. A document that has the Z39.98-2012 Structural Semantics Vocabulary as its default, for example, would allow the use of the chapter term from that vocabulary as follows:

                    
<section role="chapter">
  …
</section>

The referenced RDFa context document may also define one or more fixed prefixes for referencing terms from additional vocabularies. Example 9 shows the new markup that would result if the Z39.98-2012 Structural Semantics Vocabulary were instead associated with the prefix struct.

                    
<section role="struct:chapter">
  …
</section>

If additional vocabularies not defined in the RDFa context document are needed, the prefix attribute must be attached to the document element to declare them:

                    
<document xmlns="http://www.daisy.org/ns/z3998/authoring/" xml:lang="en" prefix="foaf: http://xmlns.com/foaf/0.1/">
  …
</document>

Note that the xmlns namespace declaration attribute [XMLNAMES] must not be used to declare vocabulary prefixes.

                    
<document xmlns="http://www.daisy.org/ns/z3998/authoring/" xml:lang="en">
  <head>
    <meta property="dc:identifier" content="uid123" />
    …
  </head>
  …
</document>

8.5 Metadata

                          
…      
<head>
    …
    <meta property="dc:identifier" content="daisy-z2012-exemplar-01" />
    <meta property="dc:publisher" content="DAISY Consortium" />
    <meta property="dc:date" content="2012-07-27T18:50:05Z" />
  
    <meta rel="z3998:meta-record" resource="daisy-z2012-exemplar-01-mods.xml">
        <meta property="z3998:meta-record-type" content="z3998:mods" />
        <meta property="z3998:meta-record-version" content="3.3" />
    </meta>
    
    <meta rel="z3998:meta-record" resource="daisy-z2012-exemplar-01-onix.xml">
        <meta property="z3998:meta-record-type" content="z3998:onix-books" />
    </meta>
  
    <meta rel="z3998:meta-record" resource="http://www.example.com/meta/generator?rec=exemplar-01&amp;format=marc21">
        <meta property="z3998:meta-record-type" content="z3998:marc21-xml" />
    </meta>
    …
</head>
…            
    

<article>

<article xml:id="article01" about="#article01">

                           
<section>
  <h property="fulltitle">
    <hpart role="title">On the Origin of Species by Means of Natural Selection</hpart> or
    <hpart role="subtitle">the Preservation of Favoured races in the struggle for life</hpart>.
  </h>
   …
</section>
    

9.1 Introduction

The need to package Z39.98 documents together with the local resources they reference has always existed, but the method and format for achieving this goal has not been formally defined in previous versions of the specification. As a result, producers have had the freedom to package their document sets in any of a variety of formats as their needs required, while user agent developers have been left with the problem of handling this variation when processing the container files.

This specification seeks to redress this issue by formally defining the packaging format and MIME type [RFC2046] for bundling the local resources in Z39.98-AI document set, as well as to propose a common file extension format for the identification of container files. This approach will allow the rapid deployment and exchange of container files by removing the unnecessary ambiguity and investigation that has existed regarding their format and structure.

9.2 Format

The Z39.98-AI container format uses a modified version of the Open Container Format [OCF] to bundle into a single file all the local resources that constitute a Z39.98-AI document set. All requirements detailed in the OCF specification apply to the creation of Z39.98-AI container files, except where modified by this section.

The Z39.98-AI container format employs the modified version of the ZIP format detailed in Section 4 of [OCF]. For identifying that the file is a Z39.98-AI container, however, the following MIME type [RFC2046] must be used instead: application/z3998-auth+zip (see 9.4, Media types).

Each conformant container file must include a META-INF directory at the root of the container as per Section 3.5 of [OCF]. This directory must include the required container.xml file detailed in Section 3.5.1 of [OCF], which in turn must contain a rootfile element that points to the root Z39.98-AI document.

The root document must be identified by the MIME type application/z3998-auth+xml (see 9.4, Media types) and the container must include the root document as a resource. The container must not include references to external documents. If a document has been decomposed into smaller XML fragments, the root must be the XML file into which all the components are included to reconstitute the complete Z39.98-AI document.

The container must include the Z39.98-AI document together with all of the local resources associated with it. The container may include alternate renditions of a document, but must not contain more than a single Z39.98-AI document.

The optional reserved files allowed by the OCF specification are handled as follows:

The Z39.98-AI container format does not support OEBPS package files [OPF] and their inclusion in container files is not recommended.

Example 14 shows the structure of a typical Z39.98-AI container file.

mimetype
META-INF/
   container.xml
Z3998-AI/
   On the Origin of Species.xml
   metadata/
      mods.xml
      onix.xml
   images/
      cover.png

Example 15 shows the contents of the container.xml file. The rootfile points to the root Z39.98-AI document.

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
  <rootfiles>
    <rootfile full-path="Z3998-AI/On the Origin of Species.xml" media-type="application/z3998-auth+xml" />
  </rootfiles>
</container>

9.3 File extension

To facilitate the identification of the Z39.98-AI container files, containers should use the extension .zai. Alternate file extensions may be used so long as the container conforms with the ZIP requirements outlined in 9.2, Format.

File extensions are only a hint to the format of a container; the container’s mimetype file is the primary designator of the contents.

9.4 Media types

This specification defines the following two new media types:

Refer to Appendix C, Media type registration for more information.

10.1 Introduction

Profiles and features are fully-developed markup languages in their own rights, and typically require multiple documents to define them normatively: schemas, RDF vocabularies, and often normative prose. Profiles and features typically also provide informative resources, such as primers, best practice guides, and references to supporting software to assist users with their implementation.

To facilitate the discovery of these resources for both human and machine users alike, this specification uses [XHTML+RDFa] as the mechanism to associate a collection of normative and informative resources with a profile or a feature. The XHTML+RDFa document used to collect the references to these resources is called a resource directory.

As XHTML documents, resource directories are human-readable, and thus may serve as the primary source of information for all users of a profile or feature. Resource directories are also machine-readable documents, and thus may be sources for the discovery and retrieval of schemas, style sheets, RDF vocabularies, and other types of resources needed by processing agents.

In order to facilitate interoperability of processing agents, this specification defines a Z39.98-2012 Resource Directory Vocabulary. This vocabulary contains terms that describe and identify resources associated with profiles and features, and states how they are to be used.

10.2 Resource directory conformance definition

The resource directory for a profile or feature must be a document conforming to the [XHTML+RDFa] specification, using terms from the Z39.98-2012 Resource Directory Vocabulary as detailed below.

Note that additional resource directory requirements specific to profiles and features are defined in 6.3.3, Profile resource directory and 7.2.3, Feature resource directory respectively. All other terms defined by the Z39.98-2012 Resource Directory Vocabulary are optional.

This specification allows terms from other vocabularies than the Z39.98-2012 Resource Directory Vocabulary to be included in resource directory documents.

11.1 Introduction

The Z39.98-AI Framework makes use of [RDFa] and the role attribute to express document-level metadata and to express semantic inflections on individual elements in the document content (see 4.3.7, Metadata Attributes collection). RDF vocabularies are used to define controlled lists of terms to provide consistency in the application of metadata across profiles and between producers.

The Z39.98-AI Framework includes a set of predefined vocabularies (see A.3, Vocabulary catalog). This section describes the nature of these vocabularies and defines rules for how to associate these and additional vocabularies with a Z39.98-AI document. Rules for the processing of vocabulary terms are defined in 12.4, Processing of vocabulary terms.

11.2 Vocabularies defined by this specification

11.3 Associating vocabularies with Z39.98-AI documents

An initial context document, as defined in section 9 of [RDFa], is an [XHTML+RDFa] document that defines the default RDF vocabulary for a Z39.98-AI profile (enabling the use of unprefixed CURIEs) as well as any additional vocabulary prefixes directly supported. Each Z39.98-AI profile must specify the URI of its initial context document in its resource directory using the term z3998-rdfa-context from the Z39.98-2012 Instance Metadata Vocabulary (see 6.3.3, Profile resource directory).

Z39.98-AI profile documents must identify their initial context document in the resource attribute of a meta element specifying the relationship z3998:rdfa-context in its rel attribute.

                    
…      
<head>
  …
  <meta rel="z3998:rdfa-context" resource="http://www.daisy.org/z3998/2012/vocab/context/default/" />
  …
</head>
…

When processing a document, the default vocabulary and any prefixes defined in the initial context document must be used to dereference any CURIE values found in RDFa-compliant attributes. If, however, a child element defines its own metadata container, such as the article element, that element may define a localized context in their child metadata container element by the same means. When a localized context is defined, processors must ignore the context defined by the host document.

Only CURIEs from the default vocabulary defined in the initial context document may be referenced in their unprefixed form. The initial context document may also define CURIE prefix bindings, and these must be used to reference the associated vocabularies.

A vocabulary that has not been defined in the initial context document may still be referenced and used to attach metadata to a document. In this case, a prefix definition must be added to the document using the RDFa
prefix
attribute on the root document element. Prefixes are declared in whitespace separated pairs of the form:

NCName: URI

The prefix attribute must not be used to redeclare prefixes or URIs that have already been defined in the initial context document. The xmlns attribute must not be used to declare RDFa vocabulary prefixes.

All unprefixed CURIEs must resolve to a term in the default vocabulary in order for a document to be valid. It is not valid to use a CURIE prefix or reference terms from a vocabulary that has not been defined in the initial context document or prefix attribute.

A Z39.98-AI profile must not impose restrictions on the occurrence of references to vocabularies, except as relates to the initial context document.

11.4 Format of RDF vocabularies

This specification does not impose any restrictions on the format of RDF vocabularies associated with Z39.98-AI documents.

When developing vocabularies intended for use within the Z39.98-AI Framework, RDFa in XHTML, as defined by [XHTML+RDFa], is recommended to be the principal publication form. Implementers should be aware that vocabularies expressed in for example RDF Schema [RDFS] or Notation3 [N3] may also occur.

11.5 Changes to RDF vocabularies

Vocabularies are evolving documents, just like the profiles that reference them. The terms they contain may be modified or added to as required to augment the needs of profile and document creators. Terms should not be removed from vocabularies, however. If a term is no longer needed or has been replaced by another, its use should be deprecated.

Vocabularies are not required to identify their current version in their canonical URI, but should include a revision history. Processing agent developers consequently need to be aware that changes may occur independently of profiles and take measures to ensure that inconsistencies do not arise.

12.1 Introduction

Processing agents are the applications used to interact with a Z39.98-AI document during its lifecycle, from its creation through to its provision to end users. Primary examples include programs that facilitate the markup of documents (XML editors and word processing applications), programs that check document integrity (validators), and programs that process documents to create final output formats (transformation pipelines). Note that the definition of processing agent as used in this specification does not include applications used for consumption by end users, as this specification does not cover the user-oriented formats that may result from the transformation of a Z39.98-AI document.

Processing agents are not expected to be able to handle any Z39.98-AI document that they encounter. A processing agent declares support for profiles individually, and must abort processing whenever it encounters a document conforming to a profile that it does not support, and by default also when encountering a document conforming to a supported profile but with an unsupported version number (either newer or older). Although this restriction is severe, it ensures that documents are not rendered in a way that contradicts their intended use, and that any resulting outputs are not prone to bugs resulting from the passive application of new or out-dated rules. This draconian abort principle is primarily motivated by the anticipated use of the Z39.98-AI framework in fully automated provisioning contexts where errors must not pass through silently, and where the integrity of the output cannot be manually controlled.

A processing agent’s support for features is independent of its support for profiles, and by default the same draconian abort principle applies when encountering an unrecognized or unsupported feature. As described in 12.3, Initialization, however, features may define fallback methods that allow processing agents to adapt their behavior in a controlled manner and continue processing the document in spite of the fact that a given feature is not supported.

All processing agents should provide complete profile and feature support information to users in order to reduce the likelihood that they will be used to process incompatible documents and to ensure that they conform to user expectations.

12.2 Processing agent conformance definition

A conformant processing agent must meet all of the following criteria:

In addition, a conformant processing agent should be a conformant application as defined in XML Inclusions [XInclude], including support for Namespace Fixup, Base URI Fixup and Language Fixup of the result infoset. If it is not a conformant application as defined in XML Inclusions, it must, if set to process a document that contains elements in the XInclude namespace, issue a notification and abort processing .

A conforming processing agent is not required to be validating (i.e., support validating a given Z39.98-AI document against the schema resource(s) defined as normative in the resource directory of a given profile). A conforming processing agent may abort processing if set to process a document that is known to be invalid.

12.3 Initialization

Processing agents must execute the following ordered sequence of steps during the initial stage of processing a Z39.98-AI document:

12.4 Processing of vocabulary terms

The following rules apply to processing agents with regards to the processing of RDF vocabulary terms: