ZedAI Annotation
From zedwiki
Contents |
Annotations in ZedNext - Proposal
Annotations in ZedNext - Discussion
Annotation-related schema elements
The following, for reference, is a summary of the state of various annotation-like elements in the schema c. 3 April 2009.
d:annotation / @annoref
- annoref is an attribute that can occur on many possible elements, for example span or p. It points to the annotation via IDREF.
- annotation must be direct child of section
- Intent: provide supplemental information relating to a piece of a document. In common use, annotations are often written by someone other than the author of the main text.
d:note / d:noteref
- A noteref points TO a note via the "ref" attribute
- note has a "type" attribute, one of endpage, endsection, or endbook
- noteref contains text - presumably some sort of marker like * or (see note)
- Intent: supplemental information such as a footnote, with a specific location marked in the text.
table/summary
- A part of the table markup
- Intent: "This element provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille.
- "User agents MUST provide access to the content of the summary element. As an example, access could be provided through a menu option, a mouse-over function, or through a dialog." [1]
object
- Object is allowed to contain another objects or other content, which is considered as a fallback
- "Authors should always include alternate text as the content of the [innermost] object element declaration" [2]
- "When a user agent is able to successfully process an object element it MUST not attempt to process inner elements." [2]
[1] http://www.w3.org/TR/xhtml2/mod-tables.html#edef_tables_summary
[2] http://www.w3.org/TR/xhtml2/mod-object.html#edef_object_object
Questions / Problems
Should note and annotation be combined? They have very similar semantics, but the different methods to attaching them to locations in the text may be useful syntactically. An alternative would be to allow the two different ways (attribute or element) to refer to a single note or annotation element.
Differences between table and image fallback text. For our purposes these seem very similar; but according to XHTML2 spec, table summary is required to be made available to the user in all cases, while object fallback text is forbidden to be made available if the image is "successfully processed". Can we do something to make them more parallel?
Content models of the various annotation-related elements. We should look at making these consistent. This issue is already being considered at http://www.daisy.org/zw/ZedAI_A_Discussion_on_Inline_Content_Models
How should prodnote be brought in to Zednext? In Zed 3, the <prodnote> element was used both for long descriptions of images, and for other types of information added by a republisher. With long descriptions covered, we need to keep some mechanism for the other republisher annotations. This issue is discussed in the following sections.
Starting Assumptions about prodnotes
1. A "prodnote" can be defined as an annotation that is added by the document producer or republisher. So there are two pieces of information there that we can separate out -- the "type" of the information (annotation), and the "author" of the information (republisher).
By separating these out, we also gain the ability to (a) indicate several layers of annotation by different people, not necessarily republishers, and (b) indicate authorship of other types of information other than annotations by the same mechanism as we indicate authorship of annotations.
2. "Type" of information (eg annotation) does feel like the type of thing that could reasonably be an element - an annotation is not the same thing as a paragraph, even if it contains paragraphs. Therefore, in most of the examples below, I am using the annotation element for prodnotes.
3. Authorship does not feel like it belongs in the element name; it makes sense to express it with a metadata attribute, possibly RDFa. In keeping with our general philosophy of doing things only one way, it would be best to use the same mechanism for indicating authorship here as we use in other places, such as attributing chapters in a compilation.
Options
I can see 4 basic options on how to attribute "prodnote" type information. In evaluating them, keep in mind that it would be preferable to allow the same mechanisms to attribute authorship of other components of a document (table summary, object fallback text, newspaper article, book chapter...).
Option 0: leave authorship implicit (status quo)
<prodnote>content</prodnote>
Advantages:
- Simple; same as previous DAISY version
- RDFa could be added to provide additional information when necessary
Disadvantages:
- Doesn't generalize to cases other than republishing
- Inelegant; introduces an additional element with similar semantics to existing ones
Option 1: use a simple IDREF (or URI ref)
<annotation by="#producer">
content
</annotation>
The #producer URI (which could also be by="producer" as a straight IDREF attribute) refers to an element (presumably something like a <daisy:contributor> element) which identifies the person or organization responsible for this annotation.
Advantages:
- the "by" attribute could be required, and could be constrained by the schema to point to an existing element. In general, things enforced by the schema are easier to create using authoring tools.
Disadvantages:
- We need to define syntax & semantics
Option 2: use RDFa, with a daisy-namespaced property
<annotation about="#producer" property="daisy:annotated">
content
</annotation>
Advantages:
- Any RDFa-aware processing agent would be able to interpret this to mean that the producer is connected to this annotation by the "daisy:annotated" property.
Disadvantages:
- Slightly more verbose
- This property would have to be invented and defined by us.
- Usage probably cannot be enforced with schema (Question: how do we feel about making RDFa properties required on certain elements?)
Option 3: use RDFa with standard (Dublin Core) property
<annotation id="anno3">
<cite about="#producer" rev="dc:creator" href="#anno3"/>
content
</annotation>
The DC "creator" property is defined opposite to our hypothetical "daisy:annotated" property -- it's subject is the piece of writing, and its object is the author. This forces us to use some sort of additional element to express the connection. Here I've used "cite" nested into the annotation, but the element name & location doesn't matter to RDFa - it could be a <meta> element in the head with those same attributes.
Advantages:
- Standard syntax and well-known semantics
Disadvantages:
- Even more verbose; requires redundant id/href connection to satisfy RDFa
- Difficult to enforce with schema
Option 4
<p id="text_chunk">Some text</p> <p id="anno_chunk" role="editor-anno" about="#text_chunk" rel="annotation">I like to annotate</p> <p id="author_chunk" rel="dc:creator" about="#anno_chunk">Marisa</p>
Option 4a (overloading the @rel curie)
<p id="a">chink to be annotated</p> <annotation about="#a" rel="d:editor-anno">Thats a typo from the author - should say "chunk"</annotation>
These options illustrate some further possibilities -- using RDFa to create the connection between the annotation and the text that it is annotating (rather than using the existing @annoref attribute); using a p with a @role attribute rather than an <annotation> element, or using a DAISY-namespaced RDF relation curie to express both the fact that it is an annotation and that it was added by the editor.
More options?
