DIAGRAM Center(Bookshareも?)の非テキストコンテンツ説明テキスト作成ガイドライン

 benetechの研究部門で、アクセシビリティに関する標準化やツールの研究・開発を行っているDIAGRAM Centerが、図、表、数式、グラフなどテキストデータ化しづらく、画像データとしてDAISYやEPUBに挿入されがちなコンテンツ(以下、ここでは「非テキストコンテンツ」という。)の説明テキストについて、ガイドラインを公開しています。benetechは、プリントディスアビリティのある人にアクセシブルなコンテンツを提供するオンライン図書館であるBookshareを運営しているので、そこで利用されたりしているのでしょうか(よくわからない)。

 A4サイズで打ち出して77ページになるかなり大部なもので、科学、技術、工学、数学(STEM)系の図書に挿入される非テキストコンテンツも対象としています。
 
 Bookshareは、以下のエントリで書いたように、ボランタティアベースで制作される場合は、非テキストコンテンツは、スキャニングの段階でばっさり削られることが多そうなので、上のガイドラインはどのように活用されているのかとても気になる。

  上のガイドラインにそった説明テキストを制作するためのトレーニングツールも用意されている

 以前は、Poet Image Description Toolという説明テキスト制作用のオープンソースのソフトウェアもBenetechのgithubのリポジトリで公開していたのですが、いつの間にか上の研修ツールに置き換わっていたという・・・。

関連エントリ

W3C Publishing Working Groupで軽量SMIL(次世代SMIL?)について議論始まる

 W3CのPublishing Working Group の2017年9月18日の電話会議で、SMIL lite(軽量のSMIL)が(おそらく)始めて議論されています。先のエントリで紹介したWeb Pulications
での利用が想定されています。Web Pulications はEPUBと統合されて、EPUB4的な立ち位置になる可能性も示唆されているので、次世代SMILといえる立ち位置になりうるのかもしれません。まだ、議論は始まったばかりのようで、どこに向かうのかはわかりませんが。

 要件リストは、Essential Requirements(不可欠な要件)とAdvanced Requirements(高度な要件)にわけて整理されています。Essential Requirements はざっと見た感じ、現行のEPUB3ですでに実現できていることが並んでいるようですが、Advanced Requirements では、現行のEPUBでは実現できていない手話動画とテキストの同期も想定した動画のサポートや、音声解説を付けた動画のサポートが挙げられています。
 議事録を読むと、SMIL lite は XMLではなく、JSON で行く可能性が今のところ高そうですね。 
 なお、SMIL (Synchronized Multimedia Integration Language) は、DAISY や EPUB 3 では、テキストと音声の同期あるいは音声(録音音声またはTTSによる読み上げ)の再生の制御のために使用されています。現行の EPUB 3 におけるSMILのサポートは音声に限定されていますが、聴覚障害者のために手話動画とテキストを同期させたEPUBを作るため、動画のサポートが EPUB 3 仕様策定の段階から要望としてあがっていたようです。そういう経緯があったためか、EPUB Media Overlays 3.0の仕様では、動画をサポートしないことがわざわざ言及されています(最新の EPUB 3.1 でも同じです)。今回の SMIL lite の議論もこの経緯を受けてということだと思われます。

Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.

 
 最後に議事録からSMIL lite に関係するところを転載します(ここでも河村宏さんの名前が…)。

1. Requirement for SMIL Lite
Garth Conboy: “SMIL lite” == “grin”
Tzviya Siegman: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: link in GotoChat
… we’ve been looking at design reqs for syncronized multimedia
Rachel Comerford: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: allowing talking books to talk
Tzviya Siegman: can you give a quick overview?
Marisa DeMeglio: EPUB3 didn’t have a lot of problems with media overlays
… we can look at something lighter than SMIL
… we used a slim subset in EPUB3
… but SMIL adoption in the world at large hasn’t been huge
… so we can look at other formats
… we do need to link chunks of text with chunks of audio
… you still need structural semantics for navigation etc
… making video + text transcripts more accessible is a requirement
… and there are some things not included in media overlays
… I’ve been emailing with dweck
… like having multiple granularities of navigation–from para by para to word by word
… text + sign language
… video + descriptive audio
… all those are not covered by media overlays
… our next step is deciding what format to do
Garth Conboy: That multi-resolution MO approach was discussed some years ago, and I think prototyped in Readium, I think. It’s a cool idea.
Marisa DeMeglio: first question is about formats–XML or not XML
Dave Cramer: what’s the status of audio sync on the web at large?
Marisa DeMeglio: I don’t know of anything
Ivan Herman: I don’t know much more
… I love your understatement… SMIL adoption is terrible
… we will have to define a SMIL-lite which has any hope for implementation
Bill Kasdorf: is there an active SMIL WG?
Ivan Herman: we will also have to ensure there will be several implementations on top of browsers
Laurent Le Meur: I agree with Ivan when he says we’ll have to create polyfills
… if this is the case, if JS is the language that will use SMIL, then XML is not the best structure for that
… JSON has the lead, a structure JS loves
… SMIL is so complex, there are too many features
… we can track as JSON structure
Garth Conboy: Marisa is also correct, when saying MO/SMIL(lite) adoption in EPUB Reading Systems is pretty good.
Laurent Le Meur: as for the requirements, we should make sure the structure we define doesn’t prevent us from adding advanced features later
Ric Wright: one other area is where there is a SMIL implemenation is for animation of SVG
… this has been implemented by browsers
Avneesh Singh: the main objective of this work was lack of support of SMIL on the web
… and then additional things came up
… that were not covered in EPUB3 MO
… media fragments is the one thing in the web which is used
… if we can find out groups in web who are trying to solve similar problems
… we can try to do it together
Charles LaPierre: ETS and Mark Hakkinen has done lots of work with SMIL
… they might have some insight
… they use this for assessments
Tzviya Siegman: the larger group should comment about requirements
… this is not part of our charter… so what should we do with these requirements? What are next steps?
Ivan Herman: as usual, this was the topic I wanted to put on the queue
… that’s an admin problem
… this whole issue of SMIL lite is not in our charter, but is a necessary thing
… this would be rec-track work
… the traditional way to do something like this would be to form a separate CG
… that would look at an initial spec plus one or two polyfills, showing it is possible
… once the CG says we have this, it solves these requirements, it’s polyfilled, it has users
… the most obvious way would be to then form a new WG
Garth Conboy: From charter: “This specification should generally be a functional superset of EPUB 3.1. Functional round-tripping to/from EPUB 3.1 considered highly desirable.” So, would could argue it’s kinda in our charter, as it’s in EPUB 3.1.
Ivan Herman: I still believe something like SMIL is still necessary for the web, and not only for WP
… even if WP is driving this here
… the web in general would benefit
… we then could get experts from other places for a CG
… I have some colleagues in Amsterdam who worked on original SMIL
… some of them are still around; I can approach them
… but a WG would be too much for them
Tzviya Siegman: the next steps are to clean up requirements and share them
… we should pass this on to APA, and share with Janina
Ivan Herman: there are some other media-related groups, like a video group
… they might have feedback
… and outside w3c there are other groups
Marisa DeMeglio: to comment on SMIL
… DAISY was in smil WG
… we used SMIL more than anyone else, but used less of it
… our use case was really different from everyone else’s
… they used it for short presos, annotations, etc.
… we used for entire books
… I’m not sure that reawakening the SMIL group would be good
… we might look elsewhere for overlap
Ivan Herman: it’s going to be very light, very concentrated
Tzviya Siegman: it might come down to how you position it
… I can help with that
Avneesh Singh: that’s a valid point from marisa_demeglio
… we need more strength to make it an implementable standard
… we need to strike a balance for something useful for our requirements as well as for others
… that IPTV was looking for something like SMIL
… Hiroshi can be a liason
… and Mark H can also help
Tzviya Siegman: we have people volunteering to be liasons
… joanie might know who to talk about at the browsers
Avneesh Singh: I will contact Mark Hakkinen and Hiroshi Kawamura
Bill Kasdorf: I was going to ask Marisa if there is a link she can share that documents the subset of SMIL that is actually used by DAISY
Marisa DeMeglio: bill_kasdorf: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-overlays-def
Bill Kasdorf: marisa: thanks, I didn’t realize that the MO spec in EPUB 3.1 was the subset you were talking about. That’s great to know because that is what folks are actually using in the publishing world.