"空白ページ"への注釈

ウェブ上の注釈は、情報の共有や連携の仕組みとしてWWW誕生の直後から関心が持たれてきましたが、標準化に向けての転機になったのは、2009年のOpen Annotation Collaborations（OAC）発足です。それまでウェブ文書を中心に考えられることが多かった注釈対象を、技術の動向を踏まえて画像などのメディア資源にも広げ、ティム・バーナーズ＝リーが提唱して注目されていたLinked Data（リンクするデータ）の考え方をも取り入れようという試みがスタートしました。モデル表現の基本にはRDFが据えられます。

OACのメンバーでもあったロバート・サンダーソンは、2010年末に欧米の研究者や図書館関係者を集めて開催されていた写本デジタル化の共有技術研究会において、EmptyPagesというアイデアを発表します。古い写本は、ページの一部が抜け落ちてしまったり、一つの写本がばらばらになって複数の機関で保有されていたり、それぞれデジタル化の精度が異なったりと、単純に扱えない要素が多数あるため、抽象的な"空白ページ"を用意し、そこにデジタル画像やテキスト転写などを表示して、共有化を図ろうというのです。

空白ページの「ビュー」と画像やテキストは、「注釈」によって結び付けられます。Open Annotationの応用です。

この時点ですでに、ビューを並べる「シーケンス」、また階層構造などを記述する「レンジ」が提案に含まれていました。

共有カンバスのモデル

Open Annotationが共有注釈（Shared Annotation）を強く打ち出していたこともあってか、この"空白ページ"は共有カンバスと名付けられ、翌2011年春にSharedCanvasと銘打った論文が出されます。6月にはshared-canvas.orgを立ち上げて本格的な議論を開始、2012年6月には仕様のβ01版が作られました。

次の図は、β01版仕様書に掲載された概念図で、その後も共有カンバスにおける「注釈」の考え方を示すために用いられたものです。

ここでは、テキストはひとまず措いて、画像そのものを注釈として扱う考え方が提示されています。図をよく見ると、カンバスが注釈（Anno）のtargetに、画像がそのbodyになっていますね。これは、図2に示したOpen Annotationの基本モデルそのものであることが分かるでしょうか。

Open Annotationの注釈モデルは、注釈の対象と内容が異なるところにあってかまわないという点を重視していました。SharedCanvasに当てはめると、注釈対象であるカンバス（つまりビューア）は、注釈内容の画像とは独立して扱われます。画像を保持する機関が専用のビューアを用意するのではなく、共有されるカンバスにさまざまな画像（およびテキスト）を描くことができるというわけです。

共有カンバスは、Open Annotationに従って、RDFをそのまま（Turtleなどで）記述していました。注釈＝カンバスはRDFグラフとして表現できれば、単独でもまったく別のリソースと組み合わせても構わないことになるのですが、ツールで利用するにはカンバスを順番に並べるなどの構造化が必要なので、リスト（sc:AnnotationList）が併せて定義されました。そして、"空白ページ"で想定されていたシーケンスやレンジをリストと組み合わせられるように、これらをまとめる容れ物としてマニフェストが加えられています。

JSON-LDによる記述

ウェブ・アプリケーションの開発が盛んになり、データはJSONでの提供が期待されるようになっていました。ただJSONのキー（プロパティ）はローカルな名前でしかなく、特定の約束を前提にしたやり取りを越えてデータを広く共有するためには、グローバルな名前（URI）を組み込む手段が必要でした。

JSON-LDは、コンテクストという仕組みを導入することによって、ローカルな名前をURIとして解釈可能にする方法です。RDFをJSONで記述する構文の一つとして2010年頃に提案され、2012年にはW3CのRDF WGで正式に仕様策定を進めることになっていました。RDFによるモデルとして出発したSharedCanvasに、このJSON-LDを適用することで、JSON構文での記述が可能になるわけです。

図4に示したSharedCanvasのモデルをそのままJSON-LDで表現すれば、次のようになるでしょう。

{
    "@type": "oa:Annotation",
    "motivation": "sc:painting",
    "body": {
        "@id": "http://codh.rois.ac.jp/pmjt/iiif/200014778/200014778_00008",
        "@type": "dctypes:Image",
        "format": "image/jpeg",
    },
    "target": {
        "@id": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008",
        "@type": "sc:Canvas",
        "height": 3744,
        "width": 5616,
        "label "Page 8"
    }
}

ただこれではカンバスと画像が別の枝に分かれてしまい、「カンバス上に画像を描く」という構造と直感的にマッチしません。そこでJSONを組み立て直し、カンバスの中に注釈が入る形が考案されます。

{
    "@id": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008",
    "@type": "sc:Canvas",
    "height": 3744,
    "width": 5616,
    "label "Page 8",
    "images": [
        {
            "@type": "oa:Annotation",
            "motivation": "sc:painting",
            "resource": {
                "@id": "http://codh.rois.ac.jp/pmjt/iiif/200014778/200014778_00008",
                "@type": "dctypes:Image",
                "format": "image/jpeg",
            },
            "on": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008"
        }
    ]
}

例1と例2を、注釈を表すオブジェクト（oa:Annotationタイプ）に注目して比べると、target、bodyがそれぞれon、resourceに変わっただけであることが分かるでしょう。そしてtarget（on）の値、つまりカンバスは、入れ子オブジェクトをやめて外側に移動しました。その上で、直感的な（しかし紛らわしい）imagesプロパティを用いて（かつ画像は複数あり得るということで配列として）注釈と結びつけ、現在のIIIF表現APIの原形ができあがったのです（9月にはMetadata API 1.0が公開されています。そして次のバージョンが翌2014年に5月に出されたとき、Presentation API 2.0と名称が変更され、コンテクストURIも現在のものとなりました）。

JSON-LDはコンテクストを用いて解釈することでRDFグラフを得ることができます。上記のメタデータAPIモデル（＝IIIF表現APIモデル）からは、実はOpen AnnotationそのままのRDFが得られるようになっているのです（Open Annotationは今年2月にWeb AnnotationとしてW3C勧告となりました。IIIFマニフェストから得られるRDFは、この仕様にも準拠しています）。

カンバスから外部注釈へのリンク

例2のカンバスに対する注釈リストを、http://example.org/annolist.jsonに用意したとしましょう。カンバスからは、次のようにしてこの注釈リストを参照します。

{
    "@id": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008",
    "@type": "sc:Canvas",
    "height": 3744,
    "width": 5616,
    "label "Page 8",
    "images": [
        ...
    ],
    "otherContent": [ "http://example.org/annolist.json" ]
}

otherContentの配列要素には、上記のようにURIを直接書く他、sc:AnnotationListタイプを持つオブジェクトとして記述することもできます。

    "otherContent": [ 
        {
            "@id": "http://example.org/annolist.json",
            "@type": "sc:AnnotationList"
        }
    ]

わざわざオブジェクト型を用いる必要はないような気がしますが、Miradorはこちらしか認識できず、URIを文字列として列挙するだけではテキスト注釈を表示してくれないようです。

注釈リストの記述

注釈リストの記述は、IIIF表現APIの他のJSONファイルとほぼ同様です。

resourcesの配列要素となる注釈は、画像の場合と基本的に同じです。カンバスに表示するのであればテキストでも何でもmotivationは常にsc:painting。そして具体的な注釈内容をresourceプロパティ値として記述します。カンバスは同じファイルには含まれないわけですが、onプロパティ値としてURIを記述することによって結び付けられます。

画像の場合は外部にあるリソースを注釈から参照することになりますが、テキスト注釈の場合は、このJSONファイル内に直接記述できる方が便利です。IIIF表現API仕様では、これを埋め込みコンテンツと呼び、cnt:ContextAsTextタイプのリソースとして記述するとしています。テキストはcharsプロパティの値になります。

{
    "@context": "http://iiif.io/api/presentation/2/context.json", 
    "@id": "http://example.org/annolist.json",
    "@type": "sc:AnnotationList",
    "resources": [
        {
            "@type": "oa:Annotation",
            "motivation": "sc:painting",
            "resource": {
                "@type": "cnt:ContentAsText",
                "chars": "蝶と蜻蛉が描かれ...",
                "format": "text/plain",
            },
            "on": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008"
        }    
    ]
}

cnt:ContextAsTextは見慣れないタイプですが、先ごろW3CのノートになったRepresenting Content in RDF 1.0で定義されているものです。formatをtext/htmlとすれば、テキストにマークアップを含めることができます。

埋め込みコンテンツの他に、外部リソースの動画や音声を注釈とすることも可能です。その場合は@typeの値をdctypes:MovingImage、dctypes:Soundとし、charsの代わりに@idでメディアファイルのURIを示します（画像の場合と同じ形になります）。

カンバスの部分への注釈

注釈の重要な用途の一つが、画像の部分についての説明でしょう。これは前回レンジの記述で取り上げた、「カンバスの部分の参照」によって表現します。カンバスURIに、対象範囲の座標を示すメディアフラグメントを加えるのです。

{
    "@type": "oa:Annotation",
    "motivation": "sc:painting",
    "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "蜻蛉 一富士二鷹 人こころあきつむしともならばなれ...",
        "format": "text/plain",
    },
    "on": "http://codh.rois.ac.jp/pmjt/iiif/200014778/canvas/00008#xywh=2870,857,1016,745"
}

こうした注釈を理解できるツールなら、カンバス上に画像と注釈テキストを重ねて表示することで、画像の座標部分への注釈を表現してくれるでしょう。