Taking a stroll back into Z39.98 territory has me thinking about the Digital Image And Graphic Resources for Accessible Materials (DIAGRAM) content model, and, more specifically, whether it could be reformulated now that
longdesc appears to have a new lease on life.
Which isn’t to suggest that there’s necessarily anything wrong with the content model we have, or that it’s no longer useful, but working on the A11Y Metadata Project to get accessibility metadata into schema.org, and seeing LRMI already ahead of the game, it seems natural enough that the content model be expressible as native (X)HTML5 for cases when that is necessary. Accommodating more than one way to render information is never a bad thing, after all.
The DIAGRAM description content model, if you aren’t familiar with it, was designed to allow multiple information types to be consolidated into a single package, and to be referenceable from a
aria-describedat attribute. It’s not the case that a reader only wants a long description, after all, and that’s what the model accommodates. A summary may be useful, or even a simplified language description, both of which can be included with the long description. It also allows alternative representations of the image to be packaged: tactile and/or simplified versions.
The content model itself to express these description packages was developed using the Z39.98 framework, for a couple of reasons (at least):
- integrating with Z39.98 meant we could adapt the existing core modules and focus only on specializing the necessary elements on top
- integrating with DAISY production was the natural course to take at that time (this work was initiated pre-EPUB 3)
We did consider an attribute-based model based on the Z39.98
role attribute, that would have seen all of the components expressed as properties, but ultimately it was decided for simplicity of authoring to go with element names for the different sections.
You can see a complete example of a description on the DIAGRAM site, but here’s the basic (simplified) structure of a DIAGRAM description:
<description xmlns=""> <head> <!-- typical range of metadata from language to expected reader --> </head> <body> <summary>...</summary> <longdesc>...</longdesc> <simplifiedLanguageDescription>...</simplifiedLanguageDescription> <tactile>...</tactile> <simplifiedImage>...</simplifiedImage> </body> </description>
It’s not terribly complicated stuff, even if the full example that includes namespaces and RDFa metadata can be daunting to look at. In the vast majority of cases, you just copy the template and change the information in it, so looks can be deceiving, and tools were conceived that would allow the user to input the description fields and metadata without ever having to deal with the markup.
And it’s not like we didn’t consider HTML rendering, but how that would be done — whether it would be pre-rendered for web consumption by the producer or expected to be consumed directly by a compatible user agent — was not a problem that can be solved from the content end.
While a user agent consuming the XML and generating an HTML view is not problematic, if the transformation to HTML has to occur prior to distribution, you lose vital information without HTML equivalent semantics (i.e., the distinct descriptions just become a bunch of text).
So, naturally enough, this had me thinking about whether a schema.org implementation would have been useful to do, but my musing began after we completed the revision, around the time that we were meeting at Asilomar a year back. The A11Y Metadata project has just more firmly planted the idea in my head.
Without considering the header metadata, porting the content model itself would potentially boil down to just six properties, five matching the element names above (summary, longdesc, simplifiedLanguageDescription, tactile and simplifiedImage) and the sixth being the tour element not shown (for describing the alternative images). A Description class would seem to do the trick for these.
Taking the DIAGRAM example, a schema.org-inspired XHTML equivalent might simply be:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> </head> <body id="watercycle-desc" itemscope="" itemtype="http://schema.org/Description"> <section itemprop="summary" id="summary"> <h1>Summary</h1> <p>The image depicts the cycle of water evaporating, turning into clouds, falling back to earth in the form of precipitation and being filtered through sediment.</p> </section> <section itemprop="longdesc" id="longdesc01"> <h1>Description</h1> <p>The image depicts the natural process of evaporation and precipitation and how rain water gets filtered and cleansed through the earth's sediment.</p> <p>On the left-hand side of the image is a lake...</p> <p>A weather event such as a rainstorm eventually returns the precipitation to the ground...</p> <p>The natural filtering agents in the soil...</p> </section> <aside> <p>In the winter we get snow instead of rain.</p> </aside> <section itemprop="simplifiedLanguageDescription" id="simpledesc01"> <h1>Simplified Language Description</h1> <p>The image show how water becomes clouds, then rain, and then gets cleaned by the soil.</p> </section> <section itemprop="tactile" id="tactile01"> <h1>Tactile</h1> <object src="http://example.com/tactiles/repository/water-cycle.svg" type="image/svg+xml"/> <div itemprop="tour"> <p>In the upper left corner of the tactile…</p> </div> </section> <section itemprop="simplifiedImage" id="alt-image"> <h1>Simplified Image</h1> <object src="http://example.com/…/evaporation-lv.svg" type="image/svg+xml"/> <div itemprop="tour"> <p>Moving front the top left corner of the image…</p> </div> </section> </body> </html>
I’m not going to be so hasty as to suggest that this is a perfect solution, as there are issues I’ve glossed over in the above: I didn’t really deal with the aside being an annotation, or an addition by a teacher and not part of the original source.
More just food for thought…