ZedAI Roles Report20081026
From zedwiki
Contents |
Motivation for using Roles and RDF in Zed Next
Adding roles to DAISY elements is intended to be a mechanism to allow easier extension, and to give applications an alternate method of discovering how to process elements of a type that are not natively supported.
As we flesh out the A&I format and the DAISY distribution format(s), and further refine the use cases for each, we may find that some or all of the role information makes more sense as part of the distribution format. See below for more discussion of this.
For now, we will take the opportunity to explore ideas of what information role attributes could usefully carry, but with a caution that we may make wholesale changes in the future.
There are three uses we have discussed for defining roles and adding them to elements in ZedNext:
- to facilitate understanding of DAISY extension elements by mainstream software;
- to facilitate understanding of user extension elements by DAISY software;
- as a formal description of concepts for readers of the DAISY spec, but not for use by software.
Let's take these one by one.
1. Facilitating understanding of DAISY extension elements by mainstream software
The idea here would be to use RDF to provide fallbacks as input to the translation between the authoring format and the distribution format(s). In this case, when you load a distributable DAISY file in mainstream software that understands XHTML + SMIL, it would be shown in as useful a format as possible.
2. Facilitating understanding of user extension elements by DAISY software
The idea here would be to use roles in user extension elements to enable DAISY software to make use of such publications, without natively supporting those elements.
3. As a formal description for the specification
A taxonomy of roles lends formality to the behaviors expected by the DAISY community. Without this, interpretations of our specification vary beyond what is acceptable in terms of accessibility.
Examples
Some examples of how (1) and (2) would work:
The Authoring Format
Here is an example where a new element called d:pagenum is included in an XHTML2 document. This example is taken from [1].
<d:pagenum id="page_4" page="normal">4</d:pagenum>
This syntax says the following about page numbers:
- They follow a numbering scheme called "normal"
- the text value "4" complies with this numbering scheme
- they have an id
There is more to say about page numbers:
- They can be optionally rendered during playback.
- They represent a significant starting point in the document content.
- They belong to a set of items which can be iterated over.
- At the very least, they can be treated like the XHTML element <p>
We can express all the things we want to say about page numbers in RDF syntax:
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:d="http://www.daisy.org/ns/z3986/2008">
<!-- a list of behaviors-->
<rdf:Description about="d:behaviors">
<rdf:Bag>
<rdf:li>d:can-skip</rdf:li>
<rdf:li>d:can-navigate-to</rdf:li>
<rdf:li>d:belongs-to-sequence</rdf:li>
</rdf:Bag>
</rdf:Description>
<!-- Human-readable information about individual behaviors -->
<rdf:Description rdf:about="d:can-skip">
<rdfs:comment>The item can be optionally rendered during playback.</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:about="d:can-navigate-to">
<rdfs:comment>The item represents a significant starting point in the document content.</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:about="d:belongs-to-sequence">
<rdfs:comment>The item belongs to a set of items which can be iterated over.</rdfs:comment>
</rdf:Description>
<!-- Fallbacks -->
<rdf:Description rdf:about="d:pagenum">
<d:fallback>xhtml:p</d:fallback>
<rdfs:seeAlso rdf:resource="http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_p"/>
</rdf:Description>
</rdf:RDF>
Two things that were left out, requiring an ID and having a content scheme, are already dealt with by our NVDL/RNG documents [2].
To make a link between the source document and these RDF definitions, role attributes can be used. The source document might look like this after the addition of our roles:
<d:pagenum id="page_4" page="normal" role="d:can-skip d:can-navigate-to d:belongs-to-sequence">4</d:pagenum>
Still up for debate is how many levels of indirection to place between the document and the RDF file. In the above example, the roles list the behaviors one by one. Also to consider:
Where the role "d:pagenum" is associated to applicable behaviors in RDF :
<d:pagenum id="page_4" page="normal" role="d:pagenum"> ...
and
Where the element itself, d:pagenum, would be associated to applicable behaviors in RDF:
<d:pagenum id="page_4" page="normal">...
Translation to distribution formats
While the goal of this research was not to come up with distribution formats, they must be considered in order to see the relevance of what we propose. Please consider the examples that follow to be conceptual and not verbatim examples of the distribution specification.
Based on the above information, we can derive the following distribution formats by imagining a chain like:
ZedAI + RDF + DistributionOption = Distribution Format
Format A
Navigation file
<nav>
<page content="file.smil#par_page_4">
<text>4</text>
<audio src="page4.mp3"/>
</page>
</nav>
The page was extracted because it was associated with a role claiming it as a navigationally-significant point.
Text file
<html>
<body>
<p>My book</p>
<p role="d:can-skip d:belongs-to-sequence" id="page_4">4</p>
</body>
</html>
This is meant to represent XHTML2 with the <d:pagenum> element downgraded to <xhtml:p>.
SMIL file
<smil>
<seq>
...
<par id="par_page_4" expr="d:pagenum-on" role="d:pagenum d:belongs-to-sequence">
<text src="text.html#page4"/>
<audio src="page4.mp3"/>
</par>
</seq>
</smil>
- The behavior d:can-skip became a SMIL State expression, which will control the skippability of the element.
- The role d:pagenum was included because otherwise, SMIL has no way of knowing any semantics for the par element.
- The role d:belongs-to-sequence will indicate that this element is one of a sequence which can be iterated over.
Format B
Navigation file
<nav>
<page content="file.smil#par_page_4">
<text>4</text>
<audio src="page4.mp3"/>
</page>
</nav>
The page was extracted because it was associated with a role claiming it as a navigationally-significant point. (same as format A)
Text file
<html>
<body>
<p>My book</p>
<d:pagenum role="d:can-skip d:belongs-to-sequence" id="page_4">4</d:pagenum>
</body>
</html>
In this case the DAISY pagenum element was left intact rather than downgraded.
SMIL file
<smil>
<seq>
...
<par id="par_page_4" expr="d:pagenum-on" role="d:pagenum d:belongs-to-sequence">
<text src="text.html#page4"/>
<audio src="page4.mp3"/>
</par>
</seq>
</smil>
The SMIL file is the same as in Format A.
Potential software capabilities
Imagine three types of playback software/devices:
- Mainstream XHTML + SMIL: Understands format A. Doesn't understand our roles. Renders the page number as text/audio and offers skippability via SMIL.
- Basic DAISY player: Understands format A. Understands our roles. Renders the page number as text/audio. Offers skippability. Offers next/previous page.
- Specialized DAISY player: Understands format B (i.e. understands d:pagenum). Doesn't need our roles. Offers skippability, next/previous, go-to page, save page, print page, etc.
- A text-only player: Understands format C (not discussed here), which represents a WAI-ARIA + XHTML version of the document. Equivalencies between DAISY roles and WAI-ARIA roles [3] can be defined in RDF. As no WAI-ARIA roles were well-suited to page numbers, this is not covered here (yet).
Questions and Issues
- What else can we say about page numbers?
- They require a human-readable (multimedia) label
- What other behaviors enable accessibility?
- Should we include the content scheme for page="normal" in RDF or in the existing NVDL/RNG ?
- What is the proper RDF syntax for the examples here?
- Is <p> the best fallback for <pagenum>? We should also consider <div>, <hr> or <br>.
- In general, how would authoring software, as opposed to playback software, benefit from the role annotations?
Notes after the teleconference on Oct 27
- Are these behaviors too dtb-specific? We should consider that the output format might be PDF, Braille, etc. If a particular behavior would seem to only apply to DTB output, we could prefix it with dtb:behavior_name to let processors know that they can ignore it for other transformations.
- Another option is to not force the processors to use these roles.
- We should clearly state that we see players as not required to process RDF
- We should use a RDDL-like approach to provide a link to the RDF data from the ZedAI document. See rddl.org
- Our approach should consider how inheritance works -- but we need an element other than pagenum to really explore it.
- Some important guiding principles will be those which describe the boundaries between formats. E.g., NVDL/RNG is for defining structural and content constraints. RDF is for defining behaviors and fallbacks.
- Another goal is to have a comfortable number of levels of indirection between the roles and elements.
- The list of behaviors that we come up with over time will be extremely significant as our set of primary building blocks for document accessibility.
Some additional ideas
- Associate the d:pagenum element with a set of roles in RDF. This is cleaner than enumerating each role.
- Then provide a mechanism to override the default roles. Say you have a copyright notice page that must not be skipped:
<d:pagenum page="normal" role="mandatory_page">1</d:pagenum>
And in the RDF, the role of "mandatory_page" would override "d:pagenum" elements' default roles.
