Public working draft 23 December 2009
Editors:
James Pritchett
Recording for the Blind & Dyslexic
<jpritchett@rfbd.org>
Abstract
The Z39.86-2010A Primer is a non-normative document that provides an easily understood introduction to the technologies and concepts behind the Z39.86-2010 Authoring and Interchange Framework.
Table of Contents
List of Examples
This document provides an easily understood introduction to the technologies and concepts behind the Z39.86-2010 Authoring and Interchange Framework (Z39.86-AI Framework). It is intended to be read along with the normative specification documents, especially Z39.86 Authoring and Interchange Framework Specification. The intended audience includes developers who will be creating and working with systems that operate on Z39.86-AI documents, or who will be developing new Z39.86-AI profiles. It assumes a basic understanding of XML, XML Namespaces, and XML schema languages.
We will begin with the simplest possible valid Z39.86-AI document:
Example 1.1. A minimal Z39.86-AI document
<?xml version="1.0" encoding="UTF-8"?>
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#"
xmlns:dcterms="http://purl.org/dc/terms/"
xml:lang="en">
<head>
<meta rel="z3986dec:profile"
resource="http://www.daisy.org/z3986/2010/auth/profiles/genericdocument/1.0/"/>
<meta property="dcterms:identifier" content="daisy-z2010-exemplar-01"/>
<meta property="dcterms:publisher" content="DAISY Consortium"/>
<meta property="dcterms:date" content="2005-07-27T13:50:05-05:00"/>
</head>
<body>
<h>Hello, world.</h>
</body>
</document>
We will go through this document and explain the various markup items found there.
Z39.86-AI documents may contain a mixture of many different markup languages to
express different kinds of content. In order to keep these straight, all Z39.86-AI
documents use XML
namespaces. But while the different namespaces that may be used in a Z39.86-AI
document may vary, all Z39.86-AI documents must use the same default namespace, which is
the namespace for the Z39.86-2010 core markup:
http://www.daisy.org/z3986/2010/. In our example document, this default
namespace is declared on the root document element.
Every Z39.86-AI document references a Z39.86-AI profile. A profile defines markup designed to support the creation of XML documents from a particular type of information resource. Simple books, periodicals, newspapers, textbooks, and examinations all might require different XML vocabularies in order to be fully and clearly expressed in an XML document. Therefore, each of these kinds of resources could have a different Z39.86-AI profile that provides the tools necessary for document authors.
Our example document references the "generic document" profile, one of the profiles
defined by the Z39.86-2010 specification, using the meta element:
Example 1.2. Identifying the profile
<head>
<meta rel="z3986dec:profile"
resource="http://www.daisy.org/z3986/2010/auth/profiles/genericdocument/1.0/"/>
</head>The rel attribute value of "z3986dec:profile" here
indicates that this meta element is a profile declaration. The prefix
z3986dec is declared in the document element, and points to
the Z39.86-2010 Profile Declaration Vocabulary (we will describe vocabularies and how to
reference them in 3, Adding semantic inflections). As you can also see in the example,
profiles are identified by a unique URI, given in the resource attribute of
the meta element. The URI for each profile is defined by the agency that
created and maintains that profile (in this case, the DAISY Consortium).
At its core, a profile defines specific XML markup to be used for documents. This markup is defined using one or more normative schemas, written in a schema language such as RelaxNG. There may be other resources associated with a profile, such as translated W3C XML Schemas, and stylesheets. We will touch on other profile resources later on in this primer.
Beyond uniquely identifying the profile, the profile URI points to a location on the Internet that contains a resource directory for the profile. This resource directory contains all the information related to the profile and is described using XHTML+RDFa (as defined in RDFa in XHTML: Syntax and Processing). Resource directory documents are thus based on XHTML, which means that they can be viewed in a web browser. The document will typically have a description of the purpose of the profile, links to the normative schema and other profile resources, and to any associated specification documents. XHTML+RDFa documents are also machine-readable, which means that they can be used by systems that process Z39.86-AI documents to discover necessary schemas and other resources at run time. In sum, by following the profile link appearing in the head of the document, any person or processing system can find all the information available about that profile.
Here is a partial example of the source for a resource directory:
Example 1.3. Profile resource directory (partial)
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rd="http://www.daisy.org/z3986/2010/vocab/resourcedirectory/#"
version="xhtml+rdfa">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Resource Directory for the Z39.86-2010 Authoring and Interchange Generic
Document Profile, version 0.2</title>
<link rel="stylesheet" type="text/css" href="../../../../z3986-2010.css" />
</head>
<body>
<h1 property="dc:title">Resource Directory for the Z39.86-2010 Authoring and
Interchange Generic Document Profile, version 0.2</h1>
<div id="introduction">
<h2>Introduction</h2>
<p>The Z39.86-2010 Generic Document Profile can be used to represent a wide
range of documents, typically such that are not targeted by the more
specific of the Z39.86-2010 profiles.</p>
<p>Examples of generic documents, targeted by this profile, include:</p>
<ul>
<li>Organisation meeting minutes</li>
<li>Schedules, proceedings</li>
<li>Information leaflets</li>
<li>Letters</li>
<li>Documents off the web</li>
</ul>
<p>Being generic, this profile can also be used as a template starting
point for creators of more specific Z39.86-2010 Authoring and Interchange
profiles.</p>
</div>
<p id="maintenance-agency">This profile is maintained by the <a
href="http://TODO" rel="rd:maintenance-agency">ANSI/NISO Z39.86
maintenance committee</a>.</p>
<div id="normative-references">
<h2>Normative References</h2>
<div class="rd-section">
<h3>Identity URI</h3>
<p id="identity-uri">The canonical identity URI of this version of this
profile is <code rel="rd:token-identifier">
http://www.daisy.org/z3986/2010/auth/profiles/genericdocument/0.2/
</code>.</p>
</div>
<div class="rd-section">
<h3>Specification Compliance</h3>
<p id="spec-ref">This profile is compliant with the <a
href="../../../../z3986-2010a.html"
rel="rd:specification-compliance">Z3986-2010 Part A
Specification</a>.</p>
</div>
<div class="rd-section">
<h3>Normative schemata</h3>
<p>The normative schema of this profile is <a
href="z3986a-genericdocument.rng" rel="rd:normative-schema"
>z3986a-genericdocument.rng</a> (<em>version 0.2</em>).</p>
<p>The normative schema includes a number of modules and/or subschemas,
which are listed in <a href="#module-list">Appendix 1</a>.</p>
<p>The <em>latest version</em> of the normative schema is available at
the canonical URI <a
href="../../../../schema/z3986a-genericdocument.rng">
http://www.daisy.org/z3986/2010/schema/z3986a-genericdocument.rng</a>.
</p>
<p id="version-listing">
<a href="../index.html">A listing of all public versions of this
profile is available.</a>
</p>
</div>
</div>
<div id="informative-references">
<h2>Informative References</h2>
<div class="rd-section">
<h3 id="schema-documentation">Schema Documentation</h3>
<p>
<a href="./schemadoc/index.html" rel="rd:schema-documentation">Schema
documentation is available online</a>, and is also included in the
<a href="#archives">downloadable archives</a>.</p>
</div>
<div class="rd-section">
<h3 id="informative-schemas">Informative Schemata</h3>
<p>The following informative schemata are available:</p>
<dl>
<dt>
<a href="./resources/z3986a-genericdocument.single.rng"
rel="rd:informative-schema"
>z3986a-genericdocument.single.rng</a>
</dt>
<dd>A single file version of the normative RelaxNG schema.</dd>
<dt>
<a href="./resources/z3986a-genericdocument.xsd"
rel="rd:informative-schema">z3986a-genericdocument.xsd</a>
</dt>
<dd>A W3C XML Schema (XSD) version of the normative schema. This
schema contains approximations. It is not guaranteed that instance
documents valid to this schema will also be valid to the normative
schema. This schema should be used for authoring purposes only;
final validation should always be performed against the normative
schema.</dd>
</dl>
</div>
</div>
</body>
</html> The various resources for the profile are identified as the targets of links
within this XHTML+RDFa
document. The nature of each resource being linked to is identified using the
rel attribute of the a element. The normative schema for
the profile, for example, is found by following the link with the rel
value of rd:normative-schema.
As with XHTML and earlier versions of Z39.86, Z39.86-AI documents contain metadata in the document head. There is an intentionally small set of required metadata items: unique identifier, publisher, and date (the latter also serving as a version identifier).
Example 1.4. Basic document: metadata
<head xmlns:dcterms="http://purl.org/dc/terms/">
…
<meta property="dcterms:identifier" content="daisy-dtbook2005-exemplar-01"/>
<meta property="dcterms:publisher" content="DAISY Consortium"/>
<meta property="dcterms:date" content="2005-07-27T13:50:05-05:00"/>
…
</head>
As is described further in 5, Metadata in Detail, Z39.86-AI documents allow you to associate metadata resources with the document. These resources are intended to contain more "complete" metadata about the document (and, as sometimes needed in a republishing context, about the document source).
Following the profile identification and metadata in the document head comes our
minimal document content: a single heading, expressed with the h element.
This comes from the Z39.86-2010 core markup, and hence does not need a further namespace
identification. The Z39.86-2010 core markup defines a few basic elements and attributes
that are likely to be used in all profiles. The elements defined here include all the
basic structural elements (head, body) and attributes that are
needed throughout Z39.86-AI documents, such as xml:id
role. For our minimal document, no further markup is needed, and hence no
schema modules outside the Z39.86-2010 core are used.
That is all there is to the document, which is nevertheless a completely valid, conforming Z39.86-AI document. For those used to DTDs, the lack of a doctype and system identifier may raise the question of how one validates this document.
As we saw in Section 1.3.1, “Profile resources”, the profile's resource directory (found at the profile identification URI in the document head) defines at least one normative schema to use in validating the document. The way in which the schema validation process takes place depends on the schema langauge(s) used, and which tools are used to perform the validation.
The profile's resource directory can also reference informative schemas or DTDs, that allow authoring and (to a certain extent) validation within a variety of tools. Note however that the concept of informative means that the informative schemas are provided for utility and convenience reasons - not to perform the ultimate test on whether a document is valid or not. That latter task is reserved for the schema defined by the resource directory to be normative.
Our first example Z39.86-AI document included almost nothing beyond the core Z39.86-2010 markup. Real information resources will require much more than this, of course, and Z39.86-AI profiles will provide a variety of markup constructs to represent those structures. Here is a slightly more complex Z39.86-AI document that demonstrates this:
Example 2.1. A more complex Z39.86-AI document
<?xml version="1.0" encoding="UTF-8"?>
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#"
xmlns:dcterms="http://purl.org/dc/terms/"
xml:lang="en">
<head>
<meta rel="z3986dec:profile"
resource="http://www.daisy.org/z3986/2010/auth/profiles/book/1.0/" />
<meta property="dcterms:identifier" content="daisy-z2010-role-001"/>
<meta property="dcterms:publisher" content="DAISY Consortium"/>
<meta property="dcterms:date" content="2005-07-27T13:50:05-05:00"/>
</head>
<body>
<frontmatter>
<section>
<h property="dcterms:title">Ulysses: the condensed edition</h>
<pagebreak xml:id="pR1" value="i" />
</section>
<toc>
<h>Table of contents</h>
<entry>
<label>Chapter 1</label>
<ref for="p1">1</ref>
</entry>
<entry>
<label>Chapter 2</label>
<ref for="p3">3</ref>
</entry>
<pagebreak xml:id="pR2" value="ii" />
</toc>
</frontmatter>
<bodymatter>
<section>
<pagebreak xml:id="p1" value="1" />
<h>Chapter 1</h>
<p> Stately, plump Buck Mulligan came from the stairhead, bearing a
bowl of lather on which a mirror and a razor lay crossed. He held
the bowl aloft and intoned:
<quote xml:lang="la" its:translate="no">INTROIBO AD ALTARE DEI.</quote>
</p>
<pagebreak value="2" />
</section>
<section>
<pagebreak xml:id="p3" value="3" />
<h>Chapter 2</h>
<p> Yes I said yes I will Yes. </p>
</section>
</bodymatter>
</body>
</document>
Earlier vocabularies such as XHTML 1.0 (used in DAISY 2.02) and DTBook (used in ANSI/NISO Z39.86-2005) were based on Document Type Definitions (DTDs). Z39.86-2010 is based on a modularly-constructed schemas. Schemas can do more than DTDs: they are namespace aware, they allow the expression of intricate and complex content model constraints, and they support datatypes. All Z39.86-AI profiles define their markup using schemas in any combination of four different schema languages: RelaxNG, NVDL, W3C XML Schema, and ISO Schematron.
Schema languages naturally lend themselves to modular designs for markup languages. This means that there are multiple independent schema documents, each of which defines a set of elements and/or attributes that form a functional group. These modules can then be combined (composed) into a single vocabulary through a master "driver" schema document that brings the individual modules together and defines their interrelations. This kind of architecture will be familiar to those accustomed to object-oriented software design.
As noted above, every Z39.86-AI profile is based on the Z39.86-2010 core markup
language. This means that every profile will use the Z39.86-2010 core modules in its
master schema. While there are a very few elements that must be included in every
profile (e.g., the document element document), profiles are free to include
other Z39.86-2010 modules that are appropriate to the kind of information resource the
profile is designed to handle. In the case of the book profile, the main Z39.86-2010
modules used include, among others, the ones defining basic text structures (headings,
paragraphs, etc.), tables, notes, pagination, and internationalization
attributes.
Schema modules are designed to contain the markup definitions for targeted structures. In our sample document we see one such case: the table of contents:
Example 2.2. Table of contents in example document
<toc>
<h>Table of contents</h>
<entry>
<label>Chapter 1</label>
<ref for="p1">1</ref>
</entry>
<entry>
<label>Chapter 2</label>
<ref ref="p3">3</ref>
</entry>
<pagebreak xml:id="pR2" value="ii" />
</toc> The schema module for table of contents (z3986-toc) contains the
definitions for the toc, tocentry, label, and
pageref elements and their attributes. The book profile master schema
then includes this module and defines that toc can occur within
frontmatter. In this way the table of contents module is integrated
within the book profile's markup model. Note also that the table of contents module
itself draws upon constructs from other modules. In our example, the toc
includes an element from a different Z38.86-2010 module: the heading element
h. The table of contents module brings this into the content model for
toc.
So far, all the elements and attributes we have looked at are defined in schema modules that are part of the Z39.86-2010 specification, and hence are all in the default Z39.86-AI namespace. Just as the book profile brings in the table of contents module, so it can also bring in schema modules from other markup languages. In such a case, the elements and attributes from the other markup languages are distinguished by different namespaces.
Our example document uses one attribute from a different namespace: the
translate attribute defined by the Internationalization Tag Set
(ITS) of the W3C. This attribute is bound to the ITS namespace by the
its: prefix, which itself is declared in the document's root element:
Example 2.3. Declaration and use of the ITS namespace
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:its="http://www.w3.org/2005/11/its" xml:lang="en">
<body>
<bodymatter>
<section>
<p> Stately, plump Buck Mulligan came from the stairhead, bearing a
bowl of lather on which a mirror and a razor lay crossed. He held
the bowl aloft and intoned:
<quote xml:lang="la" its:translate="no">INTROIBO AD ALTARE DEI.</quote>
</p>
</section>
</bodymatter>
</body>
</document>
There is no limitation to the number of different schema modules that can be combined in a profile, and there is no limitation to the number of namespaces from which these may draw. Schema modules can be taken from non-DAISY namespaces (MathML, for example). When integrating different markup languages, the controlling principle should be to minimize duplication of effort.
Let us look at an example which provides more detailed information about the front parts of the book:
Example 3.1. A document with detailed frontmatter
<?xml version="1.0" encoding="UTF-8"?>
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:book="http://www.daisy.org/z3986/2010/vocab/book/#"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#"
xml:lang="en">
<head>
<meta rel="z3986dec:profile"
resource="http://www.daisy.org/z3986/2010/auth/profiles/book/1.0/"/>
<meta property="dcterms:identifier" content="daisy-z2010-role-001"/>
<meta property="dcterms:publisher" content="DAISY Consortium"/>
<meta property="dcterms:date" content="2005-07-27T13:50:05-05:00"/>
</head>
<body>
<frontmatter>
<section role="titlepage">
<object xml:id="imgfpiece" role="frontispiece" src="fpiece.jpg" >
A picture of Sir Henry Jowls with his arm around the author
</object>
<caption for="imgfpiece">Sir Henry Jowls with the author</caption>
<title property="dcterms:title">
<titlepart role="fulltitle">A true adventurer:</titlepart>
<titlepart role="subtitle">The story of Sir Henry Jowls</titlepart>
</title>
<p>By his nephew, <name property="dc:creator">Jack Flanders</name></p>
</section>
</frontmatter>
<bodymatter>
<section role="chapter">
<h>Chapter 1</h>
<p>The story begins at Inverness ...</p>
</section>
</bodymatter>
</body>
</document>
This document identifies the title page as a special structure, and provides even more detail within that, identifying an image that acts as a frontispiece, for example.
role attribute
If the Z39.86-AI book profile were to try to provide a specialized element for every
conceivable book structure, it would become too unwieldy to use. Instead, Z39.86-AI
profiles, in addition to elements, can reference vocabularies of semantic
roles that elements may play within the structure of the
document. These roles are identified using the role attribute, which is
available on every element in every Z39.86-AI profile. In our example, "title page" is
one such role that is being played by a section element, and is identified
by the role attribute value "titlepage". The use of the
role attribute in this manner thus allows for a finer-grained
differentiation of structures within a manageable set of elements in the schema.
For the role attribute to be at all useful, its values must be
generally understood by authors and processing agents, which suggests standardization.
To this end, profiles may define specific role vocabularies that
extend their markup model to provide more detail about the semantics of the markup.
Vocabularies are expressed using the Resource Description Framework (RDF). RDF is the technology behind the
"semantic web" and is a language for representing information about resources on the
World Wide Web. In the Z39.86-AI Framework, RDF is used to define semantic properties, describe their meaning, and to
relate them to other constructs.
Role vocabularies defined by Z39.86 are typically expressed via RDFa, which uses special attributes to express RDF within the well-known structure of XHTML. Here, for example, is the definition of the "title page" role in the Z39.86-2010 core vocabulary:
Example 3.2. RDFa representation of "title page" role
<div id="frontmatter-properties" about="#frontmatter-properties" typeof="rdf:Bag">
<h2>Frontmatter</h2>
<dl about="#frontmatter-properties" rev="rdfs:member">
<dt id="titlepage" about="#titlepage" typeof="rdf:Property">titlepage</dt>
<dd about="#titlepage" property="rdfs:comment" datatype="xsd:string">
Analogous to a print book's title page.
</dd>
</dl>
</div> The syntax above says that the element whose id is
titlepage is also an RDF property. This means it can be used as a role value in a document and
traced back to the definition given here. There is also a human-readable comment which
says what the meaning of titlepage is.
Each profile may define a default role vocabulary, which in that case is referenced in the profile's resource directory. However, Z39.86-AI documents are not limited to using the role vocabulary referenced by the resource directory, nor to use only vocabularies defined within the Z39.86-AI Framework. In our example document above, the Dublin Core roles of "title" and "creator" are examples of non-Z39.86-AI roles.
role in Z39.86-AI documents
As stated previously, the role value titlepage is defined
in the Z39.86-2010 core vocabulary. This example shows how to use this role value in a
document to identify a section as a "title page".
Example 3.3. Section with titlepage role
<body>
<frontmatter>
<section role="titlepage">
...
</section>
</frontmatter>
</body>
Any element in a Z39.86-AI document can reference a role via the role
attribute. The value of role is a CURIE (short for
"Compact URI"), as defined in CURIE
Syntax 1.0. Simply described, CURIEs consist of a prefix and a local part that creates a unique identifier
(URI) in a manner similar to the way that qualified names (QNames) are created using
XML namespaces. In our
example document, we find CURIEs such as book:frontispiece, where
book: is the prefix and frontispiece is the local part.
You have already noted that the role attribute value in the example above do not have
a prefix (role="titlepage" for example). This is because a Z39.86-AI
profile via its resource directory can define one vocabulary to be the default. Roles
from the default vocabulary do not need prefixes.
All CURIEs belonging to other
vocabularies than the default one however, need to be prefixed, and the association
between the prefix and a vocabulary URI must be declared in the document. In our
example, the xmlns attribute is used to declare the association between the prefix
dc and the URI http://purl.org/dc/elements/1.1/ (which is
an RDF vocabulary URI), and the same
mechanism is used to associate the book prefix with the vocabulary URI
corresponding to the Z39.86-AI Book vocabulary.
The role-defining mechanism of the Z39.86-AI Framework is inherently extensible: the
role attribute can reference any role vocabulary, not just the ones
defined by the Z39.86-2010 specification or the various profiles and features. If a
particular information resource or collection of resources require highly specialized
semantic inflections, the document author can create a role vocabulary in RDFa that is tailored for that
specific purpose. Conforming Z39.86-AI documents can then reference this custom
vocabulary. Processing agents can discover the RDFa documents to find further
information about the roles used and respond appropriately.
The examples we have seen so far are relatively generic in their content. There are cases, however, where information resources may include areas highly specialized content. A typical example would be a math textbook, in which mathematical equations would occur within the context of the book structures. The book profile can handle this by including parts of MathML in its markup model. However, this markup will only be used in some books, probably relatively few compared to the total population of print books that could be expressed using the Z39.86-AI book profile. For this reason, the Z39.86-AI Framework has defined the concept of "features": discrete components similar in structure to profiles, but which are narrower in scope and which can be included by profiles and identified by documents as they need to use them.
The advantages of separating specialized markup such as MathML in a Z39.86-AI feature are:
Reusability: a feature may be "plugged into" many different profiles without alteration, reducing the burden of implementation on profile designers.
Modularity: By keeping specialized markup in separate features, the rest of the profile's schema modules are simplified.
Processing support: Not all processing agents may wish to implement specialized markup such as MathML. By making MathML an identifiable feature within the book profile, it gives Z39.86-AI documents a mechanism for signaling their use or non-use of MathML to processing agents. Processors that can handle a feature used in a document can process it, while processors that do not support the feature can fail gracefully.
Here is an example document that includes a mathematical equation, expressed in MathML:
Example 4.1. Document with math
<?xml version="1.0" encoding="UTF-8"?>
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#"
xml:lang="en">
<head>
<meta rel="z3986dec:profile"
resource="http://www.daisy.org/z3986/2010/auth/profiles/book/1.0/">
<meta rel="z3986dec:feature"
resource="http://www.daisy.org/z3986/2010/auth/features/mathml/1.0/"/>
</meta>
<meta property="dcterms:identifier" content="daisy-z2010-pythagorean-001"/>
<meta property="dcterms:publisher" content="DAISY Consortium"/>
<meta property="dcterms:date" content="2005-07-27T13:50:05-05:00"/>
</head>
<body>
<frontmatter>
<section>
<h>The Pythagorean Theorum</h>
</section>
</frontmatter>
<bodymatter>
<section>
<h>The Pythagorean Theorum</h>
<p>Pythagorus stated:
<m:math>
<m:mi>c</m:mi>
<m:mo>=</m:mo>
<m:msqrt>
<m:msup>
<m:mi>a</m:mi>
<m:mn>2</m:mn>
</m:msup>
<m:mo>+</m:mo>
<m:msup>
<m:mi>b</m:mi>
<m:mn>2</m:mn>
</m:msup>
</m:msqrt>
</m:math>
</p>
</section>
</bodymatter>
</body>
</document> We saw earlier that profiles are identified by a meta element in the
document head. Features are identified in a similar manner, by
meta elements that are children of the profile's identifying
meta. Feature metas are noted by the rel
attribute value of "feature", again referencing the Z39.86-2010 Profile
Declaration Vocabulary. The resource attribute is a URL maintained by the
feature creator, and points to a resource directory, just as profile identifying URLs
do.
When a processing agent is presented with this document, it will detect the profile used and also that the MathML feature is used in this document. It can then respond to this in whatever way is appropriate. If it supports math, it may enable special math features, for example. Or, if it does not support math, the processor would be required to stop processing so as not to generate unreliable results.
Markup defined by Z39.86-AI features are intended to be optional parts of a profile: not all documents will take advantage of the specialized markup they provide, and not all processing systems will implement support for them. Nevertheless, all features that are included as part of a profile will be part of the normative schemas for the profile.
In order to facilitate the authoring and use of documents that do not need the special functions provided by features, profiles may provide additional, informative schemas that simply remove one or more of the features from the normative schemas. The list of features used and the list of informative schemas will be found in the profile's resource directory.
As described in Section 1.4, “Metadata”, all Z39.86-AI documents must contain the metadata items identifier, publisher, and date (the latter also serving as a version identifier). This is an intentionally minimal set of metadata items, which serves only to uniquely identify the document and its publisher.
In many circumstances, it is of course necessary to be able to express more and richer metadata about the document (and, in the case of republishing, about the document source, e.g. the work being republished). Given that various metadata expression languages exist in the world today, and given that different Z39.86-AI usage domains have different needs and requirements in terms of metadata, there is a certain amount of flexibility available with regards to how this "richer" metadata can be expressed in Z39.86-AI documents.
The key principle is that metadata resources can be external to the Z39.86-AI document itself. All we need to do in the Z39.86-AI document is to provide links to one or several such resources.
Here is an example of a MODS record being referenced from the head of a Z39.86-AI
document:
Example 5.1. Referencing an external metadata record: MODS
<head>
…
<meta rel="z:meta-record" resource="daisy-z2010-exemplar-01-mods.xml">
<meta property="z:meta-record-type"
about="daisy-z2010-exemplar-01-mods.xml" content="z:mods" />
<meta property="z:meta-record-version"
about="daisy-z2010-exemplar-01-mods.xml" content="3.3" />
</meta>
…
</head>
The link is labelled with information about the type (and, optionally, version) of the record.
The referenced resource in its turn, is an XML document using the MODS grammar:
Example 5.2. External metadata record: MODS
<mods xmlns="http://www.loc.gov/mods/v3" version="3.3">
<titleInfo>
<title>Elements of Contract Law: The Sanity Clause</title>
</titleInfo>
<identifier type="isbn13">978-1-56619-909-4</identifier>
<identifier type="isbn10">1-56619-909-3</identifier>
<identifier type="uid">ca-otnlb-0000-0000-0001</identifier>
<name>
<namePart>Otis B. Driftwood</namePart>
<role>
<roleTerm type="text">author</roleTerm>
</role>
</name>
<name>
<namePart>Mrs. Claypool</namePart>
<role>
<roleTerm type="text">editor</roleTerm>
</role>
</name>
<originInfo>
<publisher>DAISY Consortium</publisher>
<place>
<placeTerm>Zurich, Switzerland</placeTerm>
</place>
<dateCreated>2010-01-31</dateCreated>
</originInfo>
<relatedItem type="original">
<originInfo>
<publisher>Book Publisher Ltd.</publisher>
<place>
<placeTerm>New York, NY</placeTerm>
</place>
<dateIssued>2005-03-30</dateIssued>
</originInfo>
</relatedItem>
</mods>
Z39.86-AI is extensible with regards to which types of metadata expression languages
can be used in the referenced resources. Note how the meta-record-type meta
element in the first example above contains the attribute content="z:mods"
— this is in fact a reference to the Instance Metadata Declaration
Vocabulary, which contains a listing of well known metadata expression
languages. You can use any of the languages that are available in this listing. And, as
metadata expression languages evolve, this listing will be expanded.
The really ambitious metadata providers can also make use of the ability to reference several metadata records from the same document. As an example, a document could reference two MODS records, one of them MODS version 3.3 and the other version 4.0, and at the same time reference, say, an ONIX-based record.
As an alternative to the external metadata record approach as outlined above, it remains possible to provide a complete metadata record inside the Z39.86-AI document itself.
When doing so, you must still provide the meta-record and
meta-record-type meta items in the document head to clearly
signal that in this instance, the document is its own metadata resource. (See the
example below for how this is done.)
Internal metadata expressions are done using meta elements in the
document head, and/or using the RDFa attributes that are
available on most elements in the document body. By implication, you can
only use metadata expression languages that are published as RDF in this way.
The following example shows a document that provides DCMI metadata using the
property attribute on h and name elements
inside frontmatter:
Example 5.3. Internal metadata record: RDFa
<document xmlns="http://www.daisy.org/z3986/2010/" xml:lang="en-GB"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:z="http://www.daisy.org/z3986/2010/vocab/decl/#">
<head>
…
<meta rel="z:meta-record" resource=".">
<meta property="z:meta-record-type" about="." content="z:dcterms-rdfa"/>
</meta>
…
</head>
<body>
…
<frontmatter>
<section role="titlepage">
<h property="dcterms:title" role="fulltitle">
<hpart role="title"> On the Origin of Species by Means of Natural
Selection</hpart> or the
<hpart role="subtitle">Preservation of Favoured
races in the struggle for life</hpart>. </h>
<block>
<l>By <name property="dc:creator">Charles Darwin</name>, M.A.,</l> Fellow of the
royal, geological, linnœan, etc., societies; author of 'journal of researches
during h.m.s. Beagle's voyage round the world.' </block>
<block role="imprint">
<place>LONDON</place>: <name>JOHN MURRAY</name>, <place>ALBEMARLE
STREET</place>. <time>1859</time>. </block>
<block role="publisherNote">The right of Translation is reserved.</block>
</section>
…
</frontmatter>
</body>
</document>
Note how, in the head, the metadata resource is identified as ".", a
single period. This is standard abbreviated way to refer to the current document
URI. In other words, the single period is what says that this document is its own
metadata resource.
While the Z39.86-2010 Part A specification defines a handful of profiles, the specification is designed as a framework for building a wide variety of profiles to represent any kind of information resource. The Z39.86 maintenance agency will not be the only entity creating profiles: the vision is for any organization that needs to represent information resources in XML in an accessible way to be able to create a conforming profile that meets their needs (if one does not already exist). With the resource directory and role vocabulary components of the framework, processing agents should be able to easily detect new profiles and possibly be able to handle them through automated discovery of the profile's normative resources.
For an organization seeking to create a new profile, the steps involved would include:
Writing a conforming schema using the core Z39.86-2010 modules and whatever other markup is required, possibly including other Z39.86-2010 modules and Z39.86-AI features.
Possibly creating an RDF vocabulary in RDFa to enable further refinement of the semantics in the markup model.
Creating a resource directory document for the profile and hosting it at a
defined URL to be used in the profile's identifying meta.