Working draft 23 December 2009
Editors:
James Pritchett
Recording for the Blind & Dyslexic
<jpritchett@rfbd.org>
Markus Gylling
DAISY Consortium
<mgylling@daisy.org>
Abstract
The Z39.86 Authoring and Interchange (Z39.86-AI) Framework is a means of defining markup languages to represent different kinds of information resources (books, periodicals, etc.), with the intent of producing documents suitable for transformation into different universally accessible formats. It uses a modular, extensible architecture to permit the creation of any number of document models, each custom-tailored for a particular kind of information resource.
Table of Contents
This section is informative
The Z39.86 Authoring and Interchange (Z39.86-AI) Framework is a means of defining markup languages to represent different kinds of information resources (books, periodicals, etc.), with the intent of producing documents suitable for transformation into different universally accessible formats.
The Framework has been created with three major design goals in mind:
Extensibility. Because there are so many different kinds of information resources, each with its own unique needs, it is clear that no single markup language can fit all circumstances. Instead, the Framework is designed to be inherently extensible and customizable. The Framework specifies how to create a profile that can be used when representing a particular kind of information resource. If existing profiles do not meet the needs of a particular use case, an agency can create a wholly new profile, or can easily adapt an existing profile to better fit the immediate need. As new, specialized XML markup languages appear, they can easily be incorporated into profiles.
Modularity. Framework profiles build their models in discrete schema modules, building on existing schemas where possible. The schema modules created for specific profiles, in turn, can be used within other Framework profiles, or even in completely unrelated markup languages. This reduces the amount of work required for creating profiles through reuse.
In addition, specialized content types such as math or music can be defined as features: a coherent set of schema modules that is maintained separately from any profile. Features included in profiles can be identified individually, and instance documents declare whether they actually reference markup defined in those features. This allows both document authors and processing agents to negotiate support for these specialized constructs.
Self-describing. The Framework defines mechanisms that allow the markup language to document itself, without need of independent specification documents. Each profile names a resource directory (expressed in [RDFa]) that is a machine- and human-readable inventory of associated resources to help render and process content created using the profile. The Framework also makes heavy use of [RDFa]) within instance documents as a way of indicating the semantic function of elements in a way that is both machine- and human-readable.
The Z39.86-2010 Part A specification defines the following:
What a profile is and how it must be constructed
What a feature is and how it must be constructed
The requirements for a conforming document created using any given profile
A set of predefined features that may be used with profiles
A set of predefined profiles that may be used in creating documents
Separate from this specification document there are the following support documents:
A Framework primer document that gives an introduction to the design concepts and structures of profiles
A guide to profile construction that gives more technically detailed information on how to create a new Framework profile.
This section is informative
This standard is based on the specific versions of the standards and specifications referenced herein, which are used as defined except as noted by this document. Any refinement or replacement of a referenced specification by a newer or different version is not directly applicable to this standard. Conformance to this standard is based on the versions of the standards and specifications in effect at the time of this writing.
Z39.86-2010 Part B defines different end-user accessible formats for information resources. The procedures for defining markup languages and profiles given in this specification are designed to create documents that are easily transformed into the accessible formats described by Z39.86-2010 Part B. However, this is not an exclusive relationship. Documents conforming to a Framework profile may be transformed into many other formats not described by Z39.86-2010 Part B, and accessible formats described by that specification may be created from documents in formats not conforming to this specification.
Z39.86-2010 Part A and B jointly form a functional expansion of the [Z39.86-2005] specification. Z39.86-2010 Part A represents an entirely new technical direction that supersedes Section 4 “Content Format for Text” of Z39.86-2005. As such, text content files compliant under Z39.86-2005 will not be compliant under Z39.86-2010 and vice versa.
The document types defined by Z39.86-2010 Part A inherit all constraints defined by [Extensible Markup Language (XML) 1.0 (Fourth Edition)].
The original intent of this specification was to adopt a core vocabulary from [XHTML2] and build upon the compound document composition principles defined by [XHTMLMOD2]. At the time of this writing, [XHTML2] and [XHTMLMOD2]have not been made W3C Recommendations, and their future direction is unclear. The Z39.86-2010 core markup and related schema modules draw heavily on [XHTML2], even though they currently use the Z39.86-2010 namespace. Should [XHTML2] and [XHTMLMOD2] move forward as Recommendations, it is expected that these modules would change to the [XHTML2] namespace, and that the composition principles would be realigned with [XHTMLMOD2].
This section is informative
An integrated markup model (element set and grammar) and associated RDF vocabulary designed to represent information resources of a particular type.
The markup vocabulary (i.e., the gamut of element and attribute names, notations, etc.) and grammar (i.e., the prescribed use of that vocabulary) as defined by a schema. The markup model is the concrete representation in markup syntax of an abstract document model, and may be defined with varying levels of strict conformity.
An abstract unit within a markup model expressed as a schema fragment, used to consolidate markup declarations to increase the flexibility, modifiability, reuse and understanding of specific logical or semantic structures.
A markup model and associated RDF vocabulary designed to represent a limited, highly-specialized set of content structures. Typically these will require specific behaviors in processing agents. Mathematical equations, chemistry formulas, and musical notations are examples of the kinds of content structures that might be addressed by a Z39.86-AI feature. Features share the same general structure as profiles, but are more specialized and of narrower scope and are intended to be used as discrete components within profiles.
An ontology that provides a mechanism to annotate elements or element content with machine-extractable semantic information about their nature or purpose. RDF vocabularies are expressed in RDF.
A package of information regarding a profile or feature, including normative schemas, informative schemas, RDF vocabularies, documentation, stylesheets, or other associated resources. Resource directories are expressed in XHTML+RDFa (per [RDFa]).
An XML document that conforms to a Z39.86-AI profile.
A software application that processes a Z39.86-AI document for some reason. Examples include, but are not limited to, authoring tools (XML editors, XML-enabled word processors), transformation pipelines, business transfer chains, end-user provisioning interfaces, and conformance validators.
This section is normative
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
A conforming profile must meet all of the following criteria:
It must define an identity URI that meets the requirements of Section 4.2, “Identity URI”.
The identity URI must resolve to a resource directory that meets the requirements of Section 6.2, “Resource directory requirements”.
The resource directory must identify at least one normative schema written in one of the languages identified in Section 4.3.1, “Schema”.
The normative schema must meet all the requirements of Section 4.3.2, “Markup model requirements”.
If an RDF vocabulary is included as part of the profile ( see default vocab association in RD section), then it must meet the requirements of Section 4.4.2, “RDF vocabulary requirements”.
A conforming feature must meet all of the following criteria:
It must define an identity URI that meets the requirements of Section 5.2, “Identity URI”.
The identity URI must resolve to a resource directory that meets the requirements of Section 6.2, “Resource directory requirements”
The resource directory must identify at least one normative schema written in one of the languages identified in Section 4.3.1, “Schema”.
The normative schema must meet all the requirements of Section 5.3.2, “Markup model requirements”.
If an RDF vocabulary is included as part of the feature, then it must meet the requirements of Section 5.4, “RDF vocabularies”.
A document instance conforming to this specification must meet all of the following criteria:
It must be a well-formed XML Document as defined by [XML].
It must be namespace-valid as defined by [XMLNAMES].
The start tag of the root element of the document must explicitly contain a [XMLNAMES]) compliant declaration for the Z39.86-AI Core namespace, as defined by 8, Z39.86-2010 core markup model.
It must include a reference to exactly one conforming profile, following the means identified in Section 7.1, “Referencing profiles and features”.
If it uses markup from any of the features included in the referenced profile, it must include a reference to those features used and only to those used, following the means identified in Section 7.1, “Referencing profiles and features”.
It must be valid to the normative schema(s) of the referenced profile.
It must conform to any normative prose expressed (see Section 6.2, “Resource directory requirements”) in the resource directories of the referenced profile and feature(s).
It must contain metadata that meets all the requirements of Section 7.4, “Document metadata”.
It must perform CURIE prefix binding as defined in Section 7.2, “Referencing RDF vocabularies”.
A processing agent conforming to this specification must meet all of the following criteria when processing Z39.86-AI documents:
It must detect and handle profiles as specified in Section 4.2.2, “Processing agents and profile identities”
It must detect and handle features as specified in Section 5.2.1, “Processing agents and feature identities”
When processing a Z39.86-AI document, it must conform to any normative prose expressed (see Section 6.2, “Resource directory requirements”) in the referenced profile's and used feature's resource directories.
It must handle role attributes as specified in
Section 4.4.3, “Processing agents and role CURIEs”.
It must handle RDFa attributes as specified in
Section 4.4.4, “Processing agents and RDFa”.
This section is informative
The goal of the Z39.86 Authoring and Interchange Framework is to define a modular, extensible way of expressing information resources of all kinds as XML documents suitable for transformation into different universally accessible formats. Because information resources are of myriad types, no one XML markup language can be expected to be suitable for this task. Therefore, the Framework is based on the notion of document profiles: different markup languages suitable for particular information resource types, but which all follow the same overall architecture and which share many common components.
Examples of profiles might include:
A book profile for printed books of all kinds (novels, nonfiction books, student textbooks, etc.)
A poetry profile
A drama profile for plays of all kinds
A newsfeed profile for newspaper articles
A magazines and journals profile for all kinds of periodicals
A consumer medical information profile
By design, the Framework does not require any particular scope for a profile. As seen in the examples above, a profile can have a wide scope (such as a book profile) or it can have a narrow scope (such as a consumer medical information profile). While this specification includes a number of generally-useful profiles, any number of profiles may be created by any agency or individual to represent any kind of information resource. Profiles that conform to the criteria given in Section 3.1, “Profile conformance” are considered to be conforming profiles.
A profile consists of a markup model (element set and grammar, expressed as a schema) and, optionally, a vocabulary of RDF properties. The RDF vocabulary is used to provide semantic inflections on elements within the markup model. For example, a book profile might use roles defining such book structures as “preface”, “introduction”, or “acknowledgements” in order to inflect a generic “section” element.
Each profile has a unique URI associated with it, which serves as the profile's identifier. This URI resolves to a unique resource directory associated with the profile. This resource directory lists normative and informative resources that are associated with the profile.
Profiles may also include features in their markup models. Features themselves consist of markup models, but are not designed to be complete markup languages in their own right. Instead, they are designed to be included as-is in any number of profiles. The scope of features is narrower: they define markup suitable to represent specific content structures, typically of a highly specialized nature (such as math or music). Typically, a profile's included features will not all be used by every document created using that profile. In order to simplify the burden on processing agents, from their perspective features are optional, and documents declare which features are actually used.
This section is normative
Each profile must define a URI that serves as the unique identifier of the profile. This URI must be valid with respect to [RFC3986] and with respect to the following EBNF specification:
review Identity URI EBNF, use constraintdef
identity ::= protocol, home, static, name, version
protocol ::= 'http://'
home ::= urisegment
static ::= /z3986/2010/auth/profiles/
name ::= urisegment, '/'
version ::= [0-9.]*, '/'
urisegment ::= [A-Za-z0-9./]*
The provider of a profile owns the identity URI, and must assure that the profile identity URI resolves and has no public access restrictions. The profile identity URI must resolve to the resource directory for the profile (see 6, Resource directories).
The number of integer steps to use in the version segment is unspecified. Profile providers should utilize this segment to signal major and minor profile version changes.
This section is informative
An example profile identity URI is:
http://www.example.org/z3986/2010/auth/profiles/myProfile/1.0/
This section is normative
When comparing two profile identity URIs for equality, processing agents must follow the rules specified by [RFC3986]. If a Z39.86-AI document declares a profile identity that a processing agent does not recognize or does not support, the processing agent must abort processing. If a Z39.86-AI document declares a version of a profile that a processing agent does not recognize or does not support, the processing agent may abort processing or may continue, using whatever fallback mechanisms are available.
This section is normative
The markup model definition must be formally expressed using one or several (layered) normative schemas. One or several of the following schema types must be used:
RelaxNG, version 1.0 [RelaxNG]
NVDL,version 1.0 [NVDL]
W3C XML Schema, version 1.0 [XMLSchema]
ISO Schematron, version 1.0 [ISOSchematron]
The mechanism with which a profile references schema(s) and defines which are normative is defined in Section 6.2, “Resource directory requirements”.
The markup model as defined in the normative schema(s) must meet the following requirements:
All elements included in the markup model must be bound to an [XML namespace].
The markup model must meet the element model requirements defined in Section 8.2, “Core markup element model requirements”.
The markup model must meet the attribute model requirement defined in Section 8.3, “Core markup attribute model requirements”.
The markup model must not violate the datatype constraints defined in Section 8.4, “Core markup model datatype constraints”.
The markup model should enforce attributes from the Z39.86-2010 core namespace to use qualified names when used on elements that are not themselves from the Z39.86-2010 core namespace. Note: this is not implemented yet in the schemas.
The markup model of a profile may reference any number of Z39.86-AI features (as defined in 5, Features) by inclusion through the normative schema(s). If a feature is included, then when constructing content models, the profile's markup model must only reference the elements, attributes, and attribute collections identified by the feature as public structures (see Section 5.3.3, “Public structures”). Profiles must not modify the internals of the feature except where allowed by the feature's normative specification.
This section is informative
The Z39.86-AI Framework encourages the use of the XHTML
role attribute ([XHTMLRole])
to make semantic distinctions between the uses of similar content
structures in different contexts. Rather than define different
elements for "chapter" and "appendix", for example, a profile
might use a generic "section" container and use the
role attribute to carry the distinction of
"chapter" versus "appendix."
Similarly, the use of the RDFa attribute collection ([RDFa]) is encouraged to allow a generalised and extensible mechanism for expressing content metadata in machine readable form.
It is for this reason that all profiles must allow the
role attribute, and should allow the RDFa
attribute collection on all elements in the markup model (per
Section 8.3, “Core markup attribute model requirements”).
This section is normative
A profile may define exactly one RDF vocabulary as the default vocabulary using the mechanism defined in Section 6.2, “Resource directory requirements”. All CURIEs that have no explicit prefix that occur in Z39.86-AI documents referencing the profile will be assumed to refer to properties in this default vocabulary, as defined by [CURIE].
A profile must not impose restrictions on the occurence of references to other vocabularies than the profile's default in Z39.86-AI documents.
Profiles must use one of the following formats for expressing their RDF vocabularies:
This section is normative
If a processing agent claims support for a profile, it should natively recognize all role CURIEs of the default vocabulary of that profile. A processing agent may associate specialized behaviors with some or all of those role values.
A processing agent should support the dereferencing of unrecognized CURIEs in order to discover behavioral or other fallbacks.
If a processing agent does not support the dereferencing of unrecognized CURIEs, or if the vocabulary URI is inaccessible, then the processing agent must continue processing the document, basing its behavior on the carrying XML element alone.
If processing agent behavior associated with a role CURIE contradicts behavior associated with the carrying XML element, then the behavior associated with the element takes precedence.
This section is informative
Certain kinds of content structures have highly specialized requirements for representation and processing, but because of their limited scope within information resources, do not merit a separate profile on their own. Z39.86-AI features are designed to handle these kinds of structures. A classic example is that of mathematical equations. There is specialized markup available already to represent equations (MathML), but a separate “math profile” would make no sense. Instead, a “math feature” can be defined: a markup model of more limited scope that can be referenced as is by multiple profiles.
Features share the same general structure as profiles, but are more specialized and of narrower scope. Just like profiles, features consist of a markup model, but this model does not represent an entire document tree. Also like profiles, each feature has a unique URI associated with it, which serves as its identifier and which resolves to a unique resource directory associated with the feature.
Typically, a feature will have very few elements and attributes within its markup model that are suitable for direct reference within the content models defined by profiles. These public structures are defined by the feature in its associated normative prose and guarantee a consistent usage of the feature across profiles. The predictability which public structures provide will allow processing agents to build support for features independently of the profiles that might reference them.
Both profiles and features have version numbers, identified in their identity URIs. Note that the versioning of profiles and the features that they reference can be independent of one another. If a profile references a particular version of a feature, a newer version of that feature does not necessarily require a new version of the profile. In most cases, if the elements and attributes from the feature that are used by the profile do not change, then the profile can remain unchanged as well. The decision to issue a new version of the profile because of a feature upgrade is entirely up to the profile's maintainer, based on whatever criteria is appropriate (e.g., if backwards incompatible changes are introduced, such as the introduction of new elements or attributes, or changes to the host integration pattern of the feature). Because of this version independence of profiles and features, processing agents will need to take this into account and indicate separately what versions of the various profiles and features they support.
This section is normative
Each feature must define a URI that serves as the unique identifier of the feature. This URI must meet all the requirements of a profile identity URI (as defined in Section 4.2, “Identity URI”), with the following change in the EBNF specification:
static ::= /z3986/2010/auth/features/
The feature identity URI must resolve to the resource directory for the feature.
With regards to recognizing and responding to declared feature identities and versions, processing agents must meet all the requirements for profiles given in Section 4.2.2, “Processing agents and profile identities”.
This section is normative
Features must use one or more of the same schema types as profiles for their normative schemas (as defined in Section 4.3.1, “Schema”).
The markup model as defined in the normative schema(s) must meet the following requirements:
All elements included in the markup model must be bound to an [XML namespace].
The namespace of elements and attributes defined by feature must not be the Z39.86-AI Core namespace. (Note however that a feature may reuse elements in the Z39.86-AI Core namespace in internal content models)
The markup model must meet the attribute model constraints defined in Section 8.3, “Core markup attribute model requirements”.
The markup model must not violate the datatype constraints defined in Section 8.4, “Core markup model datatype constraints”.
All features must identify which elements, attributes, and attribute collections within its markup model are to be considered public structures. Public structures are the only elements, attributes, and attribute collections that may be referenced directly by a profile in its markup model. The identification of public structures must be made in a normative prose document associated with the feature through its resource directory (see Section 6.2, “Resource directory requirements”).
This section is normative
Features may define one or more RDF vocabularies, but must not define a default vocabulary, as in any given document they inherit the default vocabulary (if any) of the host profile (see Section 4.4.2, “RDF vocabulary requirements”).
RDF vocabularies for features must be expressed in the languages defined for profiles in Section 4.4.2, “RDF vocabulary requirements”.
This section is informative
Profiles and features are fully-developed markup languages in their own rights, and hence will require multiple documents to define them normatively: schemas, RDF vocabularies, possibly normative prose. Profile and feature users will also benefit from informative resources, such as stylesheets, primers documents, etc. Users, both human and machine, need a way to locate these profile- and feature-specific resources. This specification uses XHTML+RDFa (as defined in [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 can serve as the primary source of information for all users of a profile. Resource directories are also machine-readable documents, and thus can be sources for the discovery and retrieval of schemas, style sheets, RDF vocabularies and other types of resources that are needed by processing agents.
Ideally, a resource directory will contain a rich variety of resources useful to both human and machine users of profiles: documentation, primers, schemas, stylesheets for both rendering and transformation of documents, role vocabularies, etc.
In order to facilitate interoperability of processing agents, this specification defines a resource directory vocabulary Z39.86 Resource Directory Vocabulary. The vocabulary contains properties that describe and identify resources associated with profiles and features, and states how they are to be used. This set of terms may then be extended further by the creators of specific profiles as needed.
This section is normative
Resource directory syntax requirements need a more precise definition, possibly including a Schematron schemaThe resource directory for a profile or feature must be a document conforming to the [RDFa] specification, using properties from the Z39.86 Resource Directory Vocabulary as detailed below.
The resource directory must include a reference to at least
one normative schema resource. The RDF property used to
identify that resource must be
normative-schema.
The resource directory must include one or more references
to relevant normative external specifications to which the
profile or feature being described adheres. The RDF property
used to identify that resource must be
specification-compliance.
In addition to a normative schema, a profile
may provide additional normative
specification through prose. A feature
must provide normative prose that
includes an identification of its public structures (see
Section 5.3.3, “Public structures”). Such
resources must be identified using the
normative-prose property.
The resource directory for a profile may identify one RDF
vocabulary as the default. The RDF property used for that
resource must be default-vocabulary. Resource
directories for features must not contain the
default-vocabulary property.
It is recommended that the resource directory include at
least one resource whose property is reference
and which resolves to a human-readable description of the
profile's or feature's purpose and structure.
This specification allows properties from other vocabularies than the Z39.86 Resource Directory Vocabulary to be included in resource directory documents.
For profile resource directories, features included in the
profile must be identified. Links to features in the resource
directory are identified by the feature
property.
The vocab should be extended to be able to express the target for normative prose: documents constraints, processing agents behavioral constraints. The vocab should be extended to be able to express the equivalent of RDDL natures. The vocab should be extended to be able to express transformation relationships (to and from the profile or feature being described).
This section is normative
A Z39.86-AI document must reference exactly one Z39.86-AI profile, and must be valid with respect to the normative schema(s) for that profile.
Documents reference profiles via the meta element
defined in the Z39.86-2010 core markup model, occurring as a child of
the head element. The profile's identity URI is given in
the resource attribute. The value of the
rel attribute must reference the definition of the
term “profile”, as found in the Z39.86-2010 Instance Metadata
Declaration Vocabulary. Therefore, the URI for this vocabulary
(http://www.daisy.org/z3986/2010/vocab/decl/) must
be bound to a CURIE prefix using the xmlns:
syntax.
If the referenced profile includes one or more features, then the
document must explicitly identify those features that are used within
the document. A feature is also referenced via the meta
element, occurring as a child of the meta element that
references the profile. In referencing features, the
rel attribute must reference the definition of the
term “feature” as found in the Z39.86-2010 Instance
Metadata Declaration Vocabulary.
This section is informative
The following is an example of a compliant profile and feature
reference in the head element for a Z39.86-AI
document.
<document xmlns="http://www.daisy.org/z3986/2010/"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#" xml:lang="en-US">
<head>
<meta rel="z3986dec:profile"
resource="http://purl.oclc.org/z3986/2010/auth/profiles/sciencejournal/1.0/">
<meta rel="z3986dec:feature"
resource="http://www.daisy.org/z3986/2010/auth/features/mathematics/3.0/" />
<meta rel="z3986dec:feature"
resource="http://www.daisy.org/z3986/2010/auth/features/chemistry/1.1/" />
</meta>
</head>
</document>
This section is normative
A Z39.86-AI document must perform CURIE prefix binding in the following way:
The document must use default-prefixed CURIEs (i.e., CURIEs with no explicit prefix given) only for CURIEs referencing the default vocabulary of the profile (See Section 4.4.2, “RDF vocabulary requirements”)
Non-default CURIE prefixes must be declared using the
xmlns attribute.
Note: use of xmlns for this purpose pending change.
This section is informative
Z39.86-AI documents should reference CSS Stylesheets using the syntax defined in [XMLSTYLE].
Note - revision underway: http://lists.w3.org/Archives/Public/public-xml-core-wg/2009Aug/0018.html
This section is informative
Access to comprehensive metadata is critical to producers, distributors, and consumers of books and other digital resources. Fulfilling this need is complicated, however, by the wide variety of standards and applications of metadata. Different insitutions have adopted different metadata standards, seeking those in alignment with their operations. And across institutions, publication metadata is consumed by many different systems during production and delivery, each with their own requirements.
In response to this situation, Z39.86-AI adopts an open metadata model that allows incorporation of metadata by reference rather than by inclusion within the document itself. Z39.86-AI documents will be read and used by conforming processing agents. While some or all of these systems might have need of bibliographic or other metadata about a publication, using the Z39.86-AI document itself as the source of this metadata is not an intuitively sound design decision. An end-user delivery system, for example, would find it much more efficient to get information about the publication from a library database than by opening the actual authoring format XML document and parsing it for standard metadata.
There is no imperative that the complete publication metadata actually appear in the publication itself, so long as the publication can be unambiguously identified and include information on how to obtain additional metadata. With that information, a processing agent can get whatever other information might be necessary—if any—to complete its work.
The metadata requirements for a Z39.86-AI document therefore serve two purposes:
To uniquely identify the document and its publisher
To provide references to one or more resources that provide more detailed metadata
Z39.86-AI documents use mandated Dublin Core metadata to identify the document and its publisher. Additional metadata is referenced by URI using constructs defined by an RDF vocabulary. The method of linking to metadata encompasses strategies as simple as a self-reference to the document itself (if the producer chooses to include metadata within the document), or as complex as URIs to web services that allow the querying of producer databases directly. Multiple complementary metadata may be referenced, allowing for different metadata standards to be used by different kinds of systems.
This section is normative
Every conforming Z39.86-AI document must include a minimal set
of metadata, defined below, that uniquely identify the document
and its publisher. Metadata is referenced using the
meta element within the head element
of the document. Metadata items are given as name-value pairs. The property attribute is used to
identify the name of the metadata item and the
content attribute, or alternatively meta element content, contains the actual metadata item
value.
The metadata names used are taken
from the Dublin Core Metadata Initiative ([DCMI]) vocabulary. Therefore, all
property attribute values must reference properties in the [DCMI] vocabulary
(http://purl.org/dc/terms/).
Every conforming Z39.86-AI document must contain the following three metadata items:
identifierA string that uniquely identifies the document as created by the document producer. Note that, in the case of a republisher, this identifier should not refer to the document source (e.g., a print book that is being republished as a digital talking book).
publisherThe name of the publisher of this document.
dateThe date this document was created or last edited. For the purposes of Z39.86-AI documents, this value also serves as a version identifier. Per [DCMI] recommendations, this value must be in W3C dateTime format.
This section is normative
Z39.86-AI documents may refer to any number of metadata resources. These may include files (either local or remote), web services, or any other resource that can be referenced by a URI (including the Z39.86-AI document itself).
Metadata resources are identified using
meta elements within the document head
with the following required attributes:
relMust refer to the
meta-record term in the Z39.86-AI
Profile Declaration vocabulary (Z39.86 Profile Declaration Vocabulary).
hrefMust be a valid, resolving URI that points to the metadata resource.
contentMust refer to one of the terms in the Z39.86-AI vocabulary that refer to metadata standards.
Each metadata resource identified in the document must also
have its type identified. This is done using an additional
meta element with the following mandatory
attributes:
propertyMust refer to the
meta-record-type term in the Z39.86 Instance Metadata
Declaration Vocabulary (Z39.86 Profile Declaration Vocabulary).
aboutMust be the URI of the external metadata resource.
contentMust refer to one of the terms in the Z39.86 Instance Metadata Declaration Vocabulary (Z39.86 Profile Declaration Vocabulary) that refer to metadata standards.
In addition, the specific version of the metadata type may be
identified using a meta element with the following
required attributes:
propertyMust refer to the
meta-record-version term in the Z39.86 Instance Metadata Declaration Vocabulary (Z39.86 Profile Declaration Vocabulary).
aboutMust be the URI of the external metadata resource.
contentMust be a string identifying the metadata standard version.
This section is informative
The following is an example of the metadata in the
head element of a Z39.86-AI document.
<head xmlns:z="http://www.daisy.org/z3986/2010/vocab/decl/#"
xmlns:dcterms="http://purl.org/dc/terms/">
…
<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" />
<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>
<meta rel="z:meta-record" resource="daisy-z2010-exemplar-01-onix.xml">
<meta property="z:meta-record-type"
about="daisy-z2010-exemplar-01-onix.xml" content="z:onix" />
</meta>
…
</head>Note that the use of nested meta elements for
external metadata resources is not a mandatory style of markup.
This section is informative
Metadata can also be expressed inline (i.e. on elements in the document body) using [RDFa]. This mechanism for specifying
metadata can either be used to provide publication-level metadata as outlined in Section 7.4, “Document metadata”, or to provide metadata for document fragments.
This specification does not mandate the use of any specific RDF vocabulary for inlining metadata information, but relies on the vocabulary assocation mechanism defined by [RDFa]. If producers create their own vocabularies, they should make the vocabulary definitions publicly available to allow validation.
This section is informative
The following is an example of the use of inline metadata in the body of a Z39.86-AI document. The example makes use of the publicly available Dublin Core RDF metadata properties.
<section xmlns:dcterms="http://purl.org/dc/terms/" >
<h property="dcterms:title">
<hpart role="fulltitle">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>
</section>
This section is informative
Logically, a Z39.86-AI document is a single XML Infoset as defined
in [XMLInfoset]. However, for authoring purposes
it may be useful to store the data in multiple physical files. By
including the xml:base attribute in all element
attribute models, all conforming Z39.86-AI Framework profiles are
compatible with [XInclude], which provides a
convenient and standards-based way to do this.
This section is normative
This section defines a collection of markup model constraints that are referenced in whole or part by 4, Profiles and 5, Features.
This section will be completely rewritten when 9, Core Module Pool - Abstract Definitions is in place.Unless explicitly overriden, the elements defined in the list below are in the Z39.86-AI Core namespace.
The root element must be document.
The root element must have exactly two element children;
first head then body.
The head element must have one meta child
element that satisfies the requirements in Section 7.1, “Referencing profiles and features”.
The head element must have three
meta children that satisfy the requirements in
Section 7.4.2, “Required document metadata”.
All elements in the markup model must allow the following attributes to occur:
TODO qualify namespace URIs and datatypes belowThe xml:id attribute ([XMLID])
The xml:base attribute ([XMLBase])
The xml:lang attribute ([XML])
The its:dir attribute ([ITS])
The XHTML role attribute ([XHTMLRole])
All elements in the markup model should allow the following attributes to occur:
The RDFa attribute collection ([RDFa])
Issue: attribute requirements may need to be relaxed for features, because of their highly specialized nature.
This section is normative
The ID datatype ([XSD-DATATYPES]) is reserved
for use in the xml:id attribute. Note - this is not enforced at the moment - see MathML and
MODS
The CURIE datatype ([CURIE]) is reserved as the unique means to reference RDF Vocabulary properties.
This section is informative
The following example illustrates the Z39.86-AI Core markup model element constraints in document form.
<document
xmlns="http://www.daisy.org/z3986/2010/"
xml:lang="en" its:dir="ltr"
xml:base="http://daisy.org/publications/"
xmlns:z3986dec="http://www.daisy.org/z3986/2010/vocab/decl/#"
xmlns:dc="http://dublincore.org/2008/01/14/dcterms.rdf#">
<head>
<meta rel="z3986dec:profile"
resource="http://purl.oclc.org/z3986/auth/profiles/sciencejournal/1.0/" />
<meta property="dc:identifier" content="12398-5674" />
<meta property="dc:publisher" content="DAISY Consortium" />
<meta property="dc:date" content="2009-12-22T11:32:00-05:00" />
</head>
<body xml:id="body">
[...]
</body>
</document>This section is normative
TODO this section will contain abstract definitions of all modules in the Core Module Pool.
This section is normative
TODO this section will specify a single-file container format and MIME types to use when transporting Z39.86-AI documents. The container spec will inherit from Z39.86 Part B.
This section is normative
The catalog of profiles hosted and maintained by the Z39.86 Maintenance Agency is located at http://www.daisy.org/z3986/2010/auth/profiles/.
The catalog of features hosted and maintained by the Z39.86 Maintenance Agency is located at http://www.daisy.org/z3986/2010/auth/features/.
The catalog of vocabularies hosted and maintained by the Z39.86 Maintenance Agency is located at http://www.daisy.org/z3986/2010/vocab/.
This section is normative
[CURIE] CURIE Syntax 1.0 - A syntax for expressing Compact URIs . M. Birbeck, et al. 16 January 2009 [DRAFT].
[DCMI] Dublin Core Metadata Initiative Metadata Terms . 14 January 2008.
[ISOSchematron] ISO/IEC 19757-3: Rule-based validation — Schematron .
[ITS] Internationalization Tag Set (ITS) Version 1.0 . C. Lieske, et al.. 3 April 2007.
[RDFa] RDFa in XHTML: Syntax and Processing . B. Adida, et al.. 14 October 2008.
[RDFS] RDF Vocabulary Description Language 1.0: RDF Schema . D. Brickley, et al.. 10 February 2004.
[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG . 3 December 2001.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC2119) . March 1997.
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax . January 2005.
[XHTML2] XHTML 2.0 . 2009 [DRAFT].
[XHTMLMOD2] Modularization of XHTML™ 2.0 . 2009 [DRAFT].
[XHTMLRole] XHTML Role Attribute Model . 2008.
[XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition) . 15 November 2006.
[XML] Extensible Markup Language (XML) 1.0 (Fourth Edition) . November 2008.
[XMLBase] XML Base (Second Edition) . 28 January 2009.
[XMLID] xml:id Version 1.0 . 9 September 2005.
[XMLInfoset] XML Information Set (Second Edition) . 4 February 2004.
[XMLNAMES] Namespaces in XML 1.0 (Second Edition) . 16 August 2006.
[XMLSchema] XML Schema: Specifications .
[XMLSTYLE] Associating Style Sheets with XML documents Version 1.0 . 29 June 1999.
[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . 28 October 2004.
[Z3986-2005] ANSI/NISO Z39.86-2005: Specifications for the Digital Talking Book . 2005.
This appendix is informative
The following are the members of the Z39.86-2010 Authoring and Interchange Working Group responsible for the creation of this specification:
The metadata portion of the specification was created by a working group including the following members:
This appendix is normative
This appendix contains the property definitions of the Z39.86 Resource Directory Vocabulary, whose online URI is http://www.daisy.org/z3986/2010/vocab/resourcedirectory/
<?xml version="1.0" encoding="utf-8"?>
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> -->
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" version="XHTML+RDFa 1.0">
<head>
<title>Z3986-2010 Resource Directory Vocabulary</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="../../z3986-2010.css" />
</head>
<body>
<h1>Z3986-2010 Resource Directory Vocabulary</h1>
<div class="informative">
<p>This vocabulary defines a set of properties for use in the <em>Z3986-2010
Resource Directory</em> document type.</p>
<p>The base grammar for a <em>Z3986-2010 Resource Directory</em> instance is <a
href="http://www.w3.org/TR/rdfa-syntax/#a_xhtmlrdfa_dtd">W3C
XHTML+RDFa</a>, with additional RDF property usage constraints expressed by
the normative <a href="TODO">Z3986-2010 Resource Directory ISO Schematron
schema</a>.</p>
</div>
<div id="rd-vocab" class="vocabulary" about="#rd-vocab" typeof="rdf:Bag">
<dl about="#rd-vocab" rev="rdfs:member">
<dt id="maintenance-agency" about="#maintenance-agency" typeof="rdf:Property"
>maintenance-agency</dt>
<dd about="#maintenance-agency" property="rdfs:comment" datatype="xsd:string"
>the maintenance agency</dd>
<dt id="specification-compliance" about="#specification-compliance"
typeof="rdf:Property">specification-compliance</dt>
<dd about="#specification-compliance" property="rdfs:comment"
datatype="xsd:string">the specification which the profile or feature
conforms to</dd>
<dt id="token-identifier" about="#token-identifier" typeof="rdf:Property"
>token-identifier</dt>
<dd about="#token-identifier" property="rdfs:comment" datatype="xsd:string">A
canonical string identifier of the profile or feature</dd>
<dt id="normative-schema" about="#normative-schema" typeof="rdf:Property"
>normative-schema</dt>
<dd about="#normative-schema" property="rdfs:comment" datatype="xsd:string"
>the normative schema</dd>
<dt id="normative-prose" about="#normative-prose" typeof="rdf:Property"
>normative-prose</dt>
<dd about="#normative-prose" property="rdfs:comment" datatype="xsd:string"
>Normative prose regarding the use of the profile or schema.</dd>
<dt id="feature" about="#feature" typeof="rdf:Property">feature</dt>
<dd about="#feature" property="rdfs:comment" datatype="xsd:string">a feature
used by the profile</dd>
<dt id="default-vocabulary" about="#default-vocabulary" typeof="rdf:Property"
>default-vocabulary</dt>
<dd about="#default-vocabulary" property="rdfs:comment" datatype="xsd:string"
>the profile's default vocabulary</dd>
<dt id="schema-documentation" about="#schema-documentation"
typeof="rdf:Property">schema-documentation</dt>
<dd about="#schema-documentation" property="rdfs:comment"
datatype="xsd:string">the schema documentation</dd>
<dt id="informative-schema" about="#informative-schema" typeof="rdf:Property"
>informative-schema</dt>
<dd about="#informative-schema" property="rdfs:comment" datatype="xsd:string"
>informative schema</dd>
<dt id="default-css" about="#default-css" typeof="rdf:Property">default-css</dt>
<dd about="#default-css" property="rdfs:comment" datatype="xsd:string">the
default cascading stylesheet used for the profile</dd>
<dt id="supporting-software" about="#supporting-software"
typeof="rdf:Property">supporting-software</dt>
<dd about="#supporting-software" property="rdfs:comment"
datatype="xsd:string">describes software that supports this profile</dd>
<dt id="examples" about="#examples" typeof="rdf:Property">examples</dt>
<dd about="#examples" property="rdfs:comment" datatype="xsd:string">examples</dd>
<dt id="module" about="#module" typeof="rdf:Property">module</dt>
<dd about="#module" property="rdfs:comment" datatype="xsd:string">a module
used in this profile</dd>
<dt id="archive" about="#archive" typeof="rdf:Property">archive</dt>
<dd about="#archive" property="rdfs:comment" datatype="xsd:string">a
downloadable archive of all the profile's documents</dd>
<dt id="reference" about="#reference" typeof="rdf:Property">reference</dt>
<dd about="#reference" property="rdfs:comment" datatype="xsd:string">a
human-readable description of the profile's purpose and structure</dd>
<dt id="prefix" about="#prefix" typeof="rdf:Property">prefix</dt>
<dd about="#prefix" property="rdfs:comment" datatype="xsd:string">a prefix
functioning as a symbolical short form for a URI</dd>
</dl>
</div>
</body>
</html>
This appendix is normative
This appendix contains the property definitions of the Z39.86 Profile Declaration Vocabulary, whose online URI is http://www.daisy.org/z3986/2010/vocab/decl/
<?xml version="1.0" encoding="utf-8"?>
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> -->
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
version="XHTML+RDFa 1.0">
<head>
<title>Z39.86-2010 Instance Metadata Declaration Vocabulary</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" type="text/css" href="../../z3986-2010.css"/>
</head>
<body>
<h1>Z39.86-2010 Instance Metadata Declaration Vocabulary</h1>
<div id="nature-properties" about="#nature-properties" typeof="rdf:Bag">
<h2>Document Instance Nature Properties</h2>
<p>The following properties are used to declare the Z39.86-2010 document instance
<em>nature</em> in terms of which profile it adheres to, and which optional features it
makes use of. The properties must be used in the <code>rel</code> attribute of the
<code>meta</code> element in the document instance <code>head</code>.</p>
<dl>
<dt id="profile" about="#profile" typeof="rdf:Property">profile</dt>
<dd about="#profile" property="rdfs:comment" datatype="xsd:string">The associated resource
reference is the canonical URI of the profile, also resolving to its Resource
Directory</dd>
<dt id="feature" about="#feature" typeof="rdf:Property">feature</dt>
<dd about="#feature" property="rdfs:comment" datatype="xsd:string">The associated resource
reference is the canonical URI of the feature, also resolving to its Resource
Directory</dd>
</dl>
</div>
<div id="meta-record-properties" about="#meta-record-properties" typeof="rdf:Bag">
<h2>Metadata Record Reference Properties</h2>
<p>The following properties are used when referencing external metadata records from a
Z39.86-2010 document instance. The properties must be used on the <code>meta</code> element
in the document instance <code>head</code>.</p>
<dl>
<dt id="meta-record" about="#meta-record" typeof="rdf:Property">meta-record</dt>
<dd about="#meta-record" property="rdfs:comment" datatype="xsd:string">The referenced
resource is an external metadata record.</dd>
<dt id="meta-record-type" about="#meta-record-type" typeof="rdf:Property"
>meta-record-type</dt>
<dd about="#meta-record-type" property="rdfs:comment" datatype="xsd:string">The referenced
metadata record is of the given <a href="#meta-record-types">type</a>. </dd>
<dt id="meta-record-version" about="#meta-record-version" typeof="rdf:Property"
>meta-record-version</dt>
<dd about="#meta-record-version" property="rdfs:comment" datatype="xsd:string">The
referenced metadata record is expressed using the given version of the given <a
href="#meta-record-type">type</a>.</dd>
<!-- example
<meta rel="z:meta-record" resource="metaRecord.xml" />
<meta property="z:meta-record-type" about="metaRecord.xml" content="z:mods" />
<meta property="z:meta-record-version" about="metaRecord.xml" content="3.3" />
and when nested
<meta rel="z:meta-record" resource="metaRecord.xml">
<meta property="z:meta-record-type" about="metaRecord.xml" content="z:mods" />
<meta property="z:meta-record-version" about="metaRecord.xml" content="3.3" />
</meta>
-->
</dl>
</div>
<div id="meta-record-types" about="#meta-record-types" typeof="rdf:Bag">
<h2>Metadata Record Types</h2>
<p>The following properties represent well-known metadata record types.</p>
<dl>
<dt id="mods" about="#mods" typeof="rdf:Property">mods</dt>
<dd about="#mods" property="rdfs:comment" datatype="xsd:string">The referenced metadata
record is of the type <a href="http://www.loc.gov/standards/mods/">Metadata Object
Description Schema</a> (MODS).</dd>
<dt id="onix-books" about="#onix-books" typeof="rdf:Property">onix-books</dt>
<dd about="#onix-books" property="rdfs:comment" datatype="xsd:string">The referenced
metadata record is of the type <a href="http://www.editeur.org/">ONIX for Books</a></dd>
<dt id="marc21-xml" about="#marc21-xml" typeof="rdf:Property">marc21-xml</dt>
<dd about="#marc21-xml" property="rdfs:comment" datatype="xsd:string">The referenced
metadata record is of the type <a href="http://www.loc.gov/standards/marcxml/">MARC 21
XML</a>.</dd>
<dt id="dcterms-rdf" about="#dcterms-rdf" typeof="rdf:Property">dcterms-rdf</dt>
<dd about="#dcterms-rdf" property="rdfs:comment" datatype="xsd:string">The referenced
metadata record is an <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF XML</a> record
using properties from <a href="http://purl.org/dc/terms/"
>http://purl.org/dc/terms/</a>.</dd>
<dt id="dcterms-rdfa" about="#dcterms-rdfa" typeof="rdf:Property">dcterms-rdfa</dt>
<dd about="#dcterms-rdfa" property="rdfs:comment" datatype="xsd:string">The referenced
metadata record is an <a href="http://www.w3.org/TR/rdfa-syntax/">RDFa</a> document using
properties from <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>.</dd>
</dl>
</div>
</body>
</html>