OPDSカタログアグリゲータにカタログの更新を知らせるPing送信

 別のブログで台湾のOPDS状況について紹介したのですが、そのエントリをマガジン航[kɔː]に転載していただきました。ありがとうございました。
.台湾がOPDSでやろうとしていること « マガジン航[kɔː]
 上の記事の中で台湾がOPDSカタログ用のPing Server(公開や更新を通知するPing送信を受けつけるサーバー)の設置を検討していることに触れました。あのエントリでは、このPing送信についてあまり踏み込んだ解説はしませんでしたが、OPDSアグリゲータに更新をしらせる仕組みとしてのPing送信は、OPDSにおいてかなり重要な要素だと思われますので、若干妄想を交えながら少し詳しく紹介したいと思います。

1. Ping送信・Ping Serverとは

 
 RSSではすでに枯れた技術でもあり、ブログを運営したことのある人ならご存じかと思いますが、Ping送信とはウェブサイトなどが更新されたことをサーバー(Ping Server)に知らせる技術です。通常のウェブサイトでは、検索エンジンのクローラが自分のサイトの更新を拾ってくれるのを基本的に待つしかませんが、ウェブサイトの運営者が更新したタイミングで更新を知らせるのでほぼリアルタイムに検索エンジンの検索結果に反映させることができます。
 少々ざっくりとしたイメージですが、以下のような流れでRSSを取得させることでサーバーに更新情報を伝えることになります。

<

figcaption>RSSアグリゲータがRSSで更新情報を取得する流れ

 詳しくは以下をご参照ください。
Ping (ブログ) – Wikipedia
PING送信の仕様 – XMLの書式、RSS配信、PINGサーバとは、ブログ・ホームページ 

2. OPDSでPing送信を活用するとこうなる

 出版社が自社サイトで電子書籍の提供するとします。

 プラットフォームに依存せずにすむという利点はあるものの、コンテンツを掲載してから検索エンジンのクローラーがウェブサイトを走行するまでに時間的間隔が開いてしまいますし、Web検索エンジン上での検索は全くジャンルの異なる他のウェブサイトと検索結果が混ざってしまいます。それは電子書籍を提供する出版社にとっても、それを探す読者にとっても望ましいものではありません。プラットフォームにコンテンツが集約されてしまう理由の1つです。
 そこで、少しでも状況を改善するためにOPDSカタログの公開し、それをOPDSアグリゲータにカタログを集約させることができればと思うのです。

 OPDSカタログの公開といっても、やることはWeb上に静的なAtom形式のファイルを置くだけですので、このままではWeb上にAtom形式のカタログがぽつんと孤立した状態で存在するだけになってしまいます。OPDSカタログアグリゲータに「あー!あー!おれはここにおるで!」「更新したから、はよ来てや!」と知らせる仕組みがあわせて必要になってくるのです。それがPing送信です。
 1で紹介したRSSのPing送信の仕組みをOPDSカタログで採用すると以下のような流れになるかと思います。

<

figcaption>OPDSアグリゲータがOPDSカタログを取得する流れ

 新たな電子書籍をWeb上で提供した、または内容を更新したときにOPDSカタログを更新し、OPDSアグリゲータが設置したPing Serverにその更新情報をPing送信によって伝えるのです。OPDSカタログアグリゲータはすぐに更新されたOPDSカタログを取得し、読者の検索結果に反映させていく。
 この仕組みの大きな利点は
電子書籍プラットフォームが対象としないコンテンツ、商用出版流通に載らないコンテンツを対象にできること
 です。これは何度強調しても足ることはありません。
 
 官公庁や研究機関などのウェブサイト上では広報誌、調査報告書、学術雑誌等々の大量のコンテンツがPDF形式で無料で公開されています。これまではWeb検索エンジンでしか見つけることができなかったこれらのコンテンツも各機関がOPDSカタログを公開し、それらアグリゲータに集約させることで他の電子書籍と一緒に検索させることができます。Webの大海に埋もれて孤立しがち、そのため容易に発見されづらいコンテンツに対して光をあてることができます。

 
 読者はOPDSカタログアグリゲータが提供する検索サービスを通じて、集約されたOPDSカタログを検索することになります。コンテンツは直接、コンテンツプロバイダのウェブサイトから取得します。RSSと同様にキーワード登録することで新刊情報をキーワードで取得するなんてことも容易に実現できるでしょう。

 有料コンテンツだと、認証の問題や課金の問題等が発生しますが、そのあたりは以下のエントリで書きましたので、ここでは省略します。OPDSはとりあえずコンテンツへのリーチを担保するための仕組みです。1つ1つ問題を解消していきましょう。
プラットフォームの束縛から電子書籍を解放する仕組みとしてのOPDSと課金(マイクロペイメント)レイヤー (2012年2月26日)

DAISY4からEPUB3への橋渡し役、DAISY Pipeline 2

 先のエントリで紹介したように、DAISY4こと、ANSI/NISO Z39.98-2012の仕様が先日正式に公開されました(以下、ANSI/NISO Z39.98-2012をDAISY4)。これはいわゆる中間(交換)フォーマットの仕様で、そのまま利用者が読書をする目的のフォーマットではありませんので、利用者が読書に利用するためにはEPUB、DAISYなどの配布フォーマットに変換する必要があります。そのDAISY4と配布フォーマットの間を橋渡しをする役目を担うのがDAISY Pipeline 2です。
DAISY Pipeline2
http://www.daisy.org/pipeline2/

(河村 宏氏の講演「DAISYの新時代―EPUB3を使って自分らしい知識のスタイルを選ぶ」より)
 今回は、DAISY4と並んで重要である配布フォーマットへの変換ツール、DAISY Pipeline2をその使用方法を含めて紹介します。なお、このエントリを書いている2012年8月22日時点で2012年7月3日に公開された2.1.3beta版が最新となっていますので、この2.1.3beta版を中心に話を進めていきます。

1.出入力フォーマット

 現時点でDAISY Pipeline 2.1.3betaで変換出来るフォーマットは主に以下の通りです。上では、DAISY4を起点にと、紹介しましたが、DAISY2.02などからもEPUB3に変換することができます。

  • DAISY2.02 → EPUB3
  • DTBook(DAISY3のXMLドキュメント) → EPUB3
  • DTBook(DAISY3のXMLドキュメント) → DAISY4 XML
  • DAISY4 XML → EPUB3

 現時点では、DAISY3、DAISY4については、出入力ともそれぞれのコンテンツファイル部分(DAISY3、DAISY4という器のなかに入っているコンテンツ本体)のみの対応になっているようです。
将来的に以下のように出入力フォーマットとしてDAISY3、DAISY4に対応していく必要があります。

  • DAISY3 → EPUB3
  • DASIY3 → DAISY4
  • DAISY4 → EPUB3

  DAISY3→EPUB3は、2012年6月以降の開発スケジュールに組み込まれています。それ以外のDAISY4→EPUB3、DASIY3→DAISY4はロードマップには掲載されていませんが、”ZedAI to EPUB 3“のLimitationの行間を読むといずれ対応するのではないかと思います。
 
 その他、ドキュメントで確認できた範囲では今後、以下の変換に対応できるようにするとのことです。

  • Word/ODT → EPUB3
  • HTML5 → EPUB3
  • DAISY4 → PEF(点字)

  点字とTTSについては、WGが立ち上がって議論が進められている(いた?)ようです。これは期待したいですね。
 点字
Pipeline 2 Working Group: Braille Production
Braille WGのまとめた要件、議事録など
 
 TTS
Pipeline 2 Working Group: TTS-based Production
TTS WGのまとめた要件、議事録など

2. インターフェイス

 DAISY Pipeline2で提供されているのは、現時点ではCI版のみです(Pipleline1はすでにGUI版の提供あり)。ローカルで実行する場合は、Windowsならコマンドプロンプト、Mac OS、Linuxならばターミナルを使用しましょう。なお、開発ロードマップによると、GUI版も2012年12月に公開される予定とのことです。
 
 また、これはユーザーというよりも開発者向けの話になりますが、開発中であるものの、Web UIとしてWebサービスとして展開することも可能なようです。
DAISY Pipeline 2 Web UI

3.DAISY Pipeline 2を使う

 
 簡単ですが、実際に使用法を紹介します。

3.1. 対応OS

 Windows/Mac OSX/Linux

3.2. ダウンロード

 以下でダウンロードできます。
Downloads – daisy-pipeline

3.3. インストール・実行環境

 とくにインストールは必要ありません。解凍したフォルダを作業しやすい適当なディレクトリに置いてください。
 ただし、プログラムの実行にはRubyとJavaを実行できる環境が必要です。詳細はREADME.txtもしくは以下を参照してください。Mac OSならば、RubyもJavaもすでにはいっているはずです。
Installing the Pipeline2
 

3.4. DAISY AI(DAISY4 Book Profile)を変換してEPUB3を生成してみる

 まずはDASIY Pipeline2の実行の基本から。README.txtに記載のあるとおり、カレントディレクトリをcliディレクトリに変更して実行します。

 
   
 では、サンプルファイルとしてついている以下のDAISY4のコンテンツファイル、alice.xmlをEPUB3に変換してみます。

  コマンドの構文は以下です。

#Windows
 cli/dp2.exe command [option]
#Mac OS/Linux
 cli/dp2 command [option] 
 

 
  今回は私はMac OS上で実行して、EPUB3に変換したのでコマンドは以下のようになります。

 
 $ cli/dp2 zedai-to-epub3 --i-source samples/zedai/alice.xml --x-output-dir  samples/output 
 

 上のコマンドを分解すると以下のようになります。

  • cli/dp2: アプリケーションの指定。Windowsなら cli/dp2.exe
  • zedai-to-epub3: zedaiからepub3を生成を命令するコマンド
  • -i-source:入力ファイルを指定するオプション。今回は”samples/zedai/alice.xml”と指定。
  • –x-output-dir:変換して出力するEPUB3の置き場所を指定するオプション。今回は”samples/output”ディレクトリ下に出力するように指定。

実行すると以下のようにソースファイルからうねうねとEPUB3へ変換していってくれます。

 
 $ cli/dp2 zedai-to-epub3 --i-source samples/zedai/alice.xml --x-output-dir samples/output
[DP2] Waiting for the WS to come up
[DP2] The daisy pipeline 2 WS is up!
[DP2] Job with id b86104ce-30c8-4527-936d-e43e6969e66b submitted to the server
[WS] INFO(1) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/alice-1.xhtml
[WS] INFO(2) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/alice-2.xhtml
          ・
          ・
          ・ 
[WS] INFO(5) - Message:copying disk file to file:/Users/hogehoge/daisy-
[WS] INFO(13) - Message:copying disk file to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/images/alice09a.png
[WS] INFO(14) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/package.opf
[DP2] The job b86104ce-30c8-4527-936d-e43e6969e66b has been deleted from the server
[DP2] DONE 
 

 
 ”DONE”と表示されると指定したディレクトリにEPUB3ファイルとEPUB3としてパッケージ化する前の状態のファイルが生成されています。

  
 今回実行したのは、zedai-to-epub3というコマンドですが、他にも以下のようなコマンドが実行できます。

  • dtbook-to-zedai(DTBookからDASIY4のコンテンツファイルに変換)
  • daisy202-to-epub3(DAISY2.02からEPUB3に変換)
  • dtbook-to-epub3(DTBookからEPUB3へ変換)

 オプション等はヘルプコマンドや以下のページでも参照することができます。samplesディレクトリにはDAISY2.02、DTBook(DAISY3)、ZedAI(DAISY4)のサンプルファイルもありますで、興味をお持ちの方はぜひお試しください。
Scripts — Short description of available scripts with links to each script
 なお、最後になりますが、以下のワークショップのスライド資料も参考になります。
Pipeline 2 Web Service Workshop: Integration and Interoperability 
  

関連エントリ

EPUB 3とDAISY 4の関係
DAISYからEPUB 3に変換する
DAISY再生ソフト・機器のEPUB対応

ANSI/NISO Z39.98-2012 (DAISY4) の読み方指南である"1.3 Overview"の 日本語訳

DAISY4こと、ANSI/NISO Z39.98-2012の仕様がついに正式に公開されました。
ANSI/NISO Z39.98-2012 Authoring and Interchange Framework for Adaptive XML Publishing Specification
http://www.daisy.org/z3998/2012/z3998-2012.html
次世代DAISY規格(ANSI/NISO Z39.98-2012)が公表 | カレントアウェアネス・ポータル
この仕様の1章3節の”Overview”がこの仕様を概観し、その読み方を指南するガイドラインになっています。読解の一助になればと”1.3 Overview”を日本語に訳してみました(以下)。あくまで非公式の翻訳ですので、参考程度にお読みください。
翻訳・解釈の正確性を保証しておりません。誤訳の指摘はコメント欄や Twitter(@kzakza) にお願いします。


原文: ANSI/NISO Z39.98-2012 (DAISY4)  1.3 Overview
http://www.daisy.org/z3998/2012/z3998-2012.html#introductionSpecOverview

1.3 Overview(概要)

この仕様に従うprofileを作成するには、このドキュメントの中で概説される様々な概念と技術が情報リソースを定義するためにどのように結びつけられているかを理解する必要がある。XMLテクノロジーに十分に慣れ、本仕様を一気に読み進められる者もいるだろうが、本概要では初心者と経験豊富な開発者のためにprofileがどのように構築されているのか、そして、どこで要件が定義されているのかについてのクイックレファレンスガイドを提供する。
Z39.98-AI の仕様の核といえるものがAbstract Document Modelである。Abstract Document Modelは全てのprofile実装を通して共通するフレームワーク、そして、文法間の一貫性と予測可能性を担保するためにprofile作成者が忠実に従わなければならないハイレベルのルールを導入する。Abstract Document Modelはprofileを構築するための地図のようなものであり、その概念は 4, Abstract Document Modelで十分に解説されている。
Abstract Document Modelは抽象的な概念を強制するルールを定めることを伴うprofile作成のプロセスであるため、Abstract Document Modelを理解することは、以下のFigure 1で描かれているような本仕様のその他の部分を理解するために不可欠である。

Overview of the Z39.98-AI profile creation process
Figure 1: Z39.98-AIプロファイル作成プロセスの概観

profileはZ39.98-AIの仕様の実質的な産物であり、情報リソースの構造を定義するmarkup modelsという形になる。profileを作成するためのそのルールと要件は 6, Profiles において詳述されている。
profileはモジュール方式モデルに基づいている。それによって、component definitions(構成要素定義) がZ39.98-AIの複数のprofileに渡って再利用できるようになり、その他の工業規格の文法を取り入れることができるようになっている。本仕様の次のセクションでは以下のようにそれらの構造における様々なパーツについて紹介する。

  • 5, Modules– moduleは意味論的にかつ/または構造的に自身を示す特質を通してリンクされた要素と属性のセットである。moduleはprofileが作成され、moduleのcomponent(構成要素)が新しい文法を構成する構成単位になった時に有効化される。
  • 5.6, Core modules– core moduleは複数のprofileに渡る構成要素の再利用を推奨するためにZ39.98-AI ワーキンググループによって開発されたmoduleのセットである。
  • 7, Features– 縮小図であるprofileと高度に専門化したmoduleの間をとったようなもので、featureは非常に特殊な構造(例えば、MathML、ルビなど)を表現するために複雑なマークアップを提供する。featureはZ39.98-AIのドキュメント類の間で専門化したマークアップの一貫性を担保し、Z39.98-AIのprofileが適切に工業規格と足並みを揃えていることを担保する助けとなる。

RDFはドキュメントのメタデータの表現と要素が持つ意味の意味論的変化(semantic inflection)のためのフレームワークによって提供される第一の手段である。profile作成者はデータに注釈をつけるために他の方法を使用するかもしれないが、 本仕様に強い結びつきのあるRDF vocabularies(RDF語彙) の使用が推奨されている。利用可能な要素と語彙を採用する方法に関する情報は11, RDF vocabulariesで参照することができる。
完成したprofileは用法とその他のドキュメントに加えスキーマファイル、RDF語彙、付加的な散文制限のような異なる様々なリソースから構成されている。profileの作成はidentity URIをprofileに割り当てる行為である(6.3.1, Profile identity URIを参照せよ)。identity URIが示す場所でリソースを一覧し、その取得する方法に関するさらなる情報を提供するresource directory ドキュメントが利用できる。resource directoryとドキュメントの作成方法に関する完全な情報は10, Resource directoriesで参照することができる。
本仕様はドキュメントの作成の際に有効な一般に利用可能にしたprofileのカタログも含んでいる(Appendix A, Profile, feature, and vocabulary catalogs で利用できる)。作成者はこれらのprofileを使用することが必須とされているわけではないが、これらのprofileはその採用を推奨するため幅広く利用されるにたり得るものとして設計された。これらのprofileは開発者や本仕様の実質的な表現を探す個人を対象にした本仕様に準拠した実装を表現している。
本仕様は特にドキュメント作成者を対象にしたものではないが、ドキュメントを識別するためにもつことが必須になっているメタデータに加え、ドキュメントが適合するprofileの指定法、使用されるfeatureなどドキュメント作成の全般的な性質に関する情報を記載している。その情報は8, Documentsで参照することができる。
本仕様は Open Container Format [OCF]をベースとしたパッケージフォーマットも取り入れており、Z39.98-AI document setを構成するXML、イメージ、その他のローカルに置かれたリソースをまとめるために利用されるかもしれない。これらのファイルの交換を容易にするためにこのコンテナフォーマットのMIME type [RFC2046] も指定している。その情報は9, ContainerAppendix C, Media type registrationで参照することができる。
プロセシングエージエント(訳者注:Z39.98-AIドキュメントを処理するアプリケーション 参照 processing agent)の開発者は上で概説した全てのトピックを充分に理解することに加え、自分が作成するアプリケーションが12.2, Processing agent conformance definitionで詳述されている適合性要件を満たすことも担保しなくてはならない。