W3C Community Draft

この文書「Open Annotation Data Model Open Annotation」（2013年2月8日付コミュニティドラフト）は、W3C の Open Annotation Community Groupによる"Open Annotation Data Model (W3C Community Draft, 08 February 2013)"の日本語訳です。この日本語訳はあくまで参考情報であり、W3Cの公式な日本語訳ではありません。翻訳・解釈に誤りがある可能性があります。原文の最新版が存在する可能性があります。

日本語訳更新日:
2014-06-05
日本語訳公開日:
2014-04-27
翻訳者:
kzakza
前のページ   目次   次のページ

目次

  1. モジュール：発行
    1. シリアライゼーション
    2. その他のリソースの埋め込み
    3. RDFグラフの埋め込み
    4. リソースの等価性

モジュール：発行

Open Annotation Data Model は、アノテーション(Annotation) がネットワークのプロトコルレベルでシステム間をどのように伝達するかについて規定していないが、概して発行に関して相互運用性のために対処しなければならない問題がいくつか存在する。これらには、外部のURIから参照されるのでははなく、アノテーション（Annotation）内にリソースを埋め込む方法、複数のシステム間の重複排除を支援するためにリソース間の等価性の表現すること、そして、名前付きグラフを用いてアノテーション（Annotation）を表現する方法が含まれている。

シリアライゼーション

アノテーション（Annotation）のシリアライゼーションは、RDFグラフを表現できるどのフォーマットでもよい（MAY）。RDFaを使用してアノテーション（Annotation） をWebページ内に埋め込むように、他のリソースに埋め込まれてもよい（MAY）。

アノテーション（Annotation）がHTTP URIを持ち、そのURIがデリファレンスされた場合には、そのアノテーション（Annotation）の表現は、適切にグラフがシリアライズされたフォーマットに戻されなくてはならない（MUST）。RDFaとして表現されたときのように、シリアライゼーションが他のリソースに埋め込まれれる形で行われた場合、このHTTP URIは、そのシリアル化されたフォーマットの中で表現され続けられなければならない（MUST）。アノテーション（Annotation）がデリファレンスされたURIから利用できず、格納するリソースに埋め込まれたもののみが利用可能な場合、UUIDやタグURIのような、グローバルにユニークなURN識別子を持っていなければならない（MUST）。

シリアライゼーションのフォーマットにJSON-LDを推奨する（RECOMMENDED） 。このフォーマットは、開発者になじみのあるツールや方法を使用することで、ウェブブラウザベースの実装で容易にアノテーション（Annotation）を利用させることができる。以下に提示するコンテキスト（Context）が実装間の一貫性を担保するために推奨される（RECOMMENDED）。このコンテキスト（Context）はhttp://www.w3.org/ns/oa-context-20130208.json で参照することができる。その他のシリアライゼーションのフォーマット、特にRDF/XMLとTurtleのコンテンツネゴシエーションをサポートすることを推奨する（RECOMMENDED）。

モデル

以下は、Open Annotation Data Model を実装するシステムでの使用が推奨される（RECOMMENDED）コンテキスト（Context）の説明である。
{
 "@context": {
    "oa" :     "http://www.w3.org/ns/oa#",
    "cnt" :    "http://www.w3.org/2011/content#",
    "dc" :     "http://purl.org/dc/elements/1.1/",
    "dcterms": "http://purl.org/dc/terms/",
    "dctypes": "http://purl.org/dc/dcmitype/",
    "foaf" :   "http://xmlns.com/foaf/0.1/",
    "rdf" :    "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs" :   "http://www.w3.org/2000/01/rdf-schema#",
    "skos" :   "http://www.w3.org/2004/02/skos/core#",

    "hasBody" :         {"@type":"@id", "@id" : "oa:hasBody"},
    "hasTarget" :       {"@type":"@id", "@id" : "oa:hasTarget"},
    "hasSource" :       {"@type":"@id", "@id" : "oa:hasSource"},
    "hasSelector" :     {"@type":"@id", "@id" : "oa:hasSelector"},
    "hasState" :        {"@type":"@id", "@id" : "oa:hasState"},
    "hasScope" :        {"@type":"@id", "@id" : "oa:hasScope"},
    "annotatedBy" :  {"@type":"@id", "@id" : "oa:annotatedBy"},
    "serializedBy" : {"@type":"@id", "@id" : "oa:serializedBy"},
    "motivatedBy" :  {"@type":"@id", "@id" : "oa:motivatedBy"},
    "equivalentTo" : {"@type":"@id", "@id" : "oa:equivalentTo"},
    "styledBy" :     {"@type":"@id", "@id" : "oa:styledBy"},
    "cachedSource" : {"@type":"@id", "@id" : "oa:cachedSource"},
    "conformsTo" :   {"@type":"@id", "@id" : "dcterms:conformsTo"},
    "default" :      {"@type":"@id", "@id" : "oa:default"},
    "item" :         {"@type":"@id", "@id" : "oa:item"},
    "first":         {"@type":"@id", "@id" : "rdf:first"},
    "rest":          {"@type":"@id", "@id" : "rdf:rest", "@container" : "@list"},

    "chars" :        "cnt:chars",
    "bytes" :        "cnt:bytes",
    "format" :       "dc:format",
    "annotatedAt" :  "oa:annotatedAt",
    "serializedAt" : "oa:serializedAt",
    "when" :         "oa:when",
    "value" :        "rdf:value",
    "start" :        "oa:start",
    "end" :          "oa:end",
    "exact" :        "oa:exact",
    "prefix" :       "oa:prefix",
    "suffix" :       "oa:suffix",
    "label" :        "rdfs:label",
    "name" :         "foaf:name",
    "mbox" :         "foaf:mbox",
    "styleClass" :        "oa:styleClass"
  }
}
図5.1.1 Open Annotation JSON-LD コンテキスト（Context）仕様

利用は以下の2つの例と同じようなシリアライゼーションになる。

{
    "@context": "http://www.w3.org/ns/oa-context-20130208.json", 
    "@type": "oa:Annotation",
    "hasBody": "http://www.example.org/body1",
    "hasTarget": "http://www.example.org/target1"
}
図5.1.2.シンプルなOpen Annotation シリアライゼーション 

{
    "@context": "http://www.w3.org/ns/oa-context-20130208.json", 
    "@id": "http://www.example.org/annotations/anno1", 
    "@type": "oa:Annotation",

    "annotatedAt": "2012-11-10T09:08:07", 
    "annotatedBy": {
        "@id": "http://www.example.org/people/person1", 
        "@type": "foaf:Person", 
        "mbox": {
            "@id": "mailto:person1@example.org"
        }, 
        "name": "Person One"
    },

    "hasBody": {
        "@id": "urn:uuid:1d823e02-60a1-47ae-ae7f-a02f2ac348f8", 
        "@type": ["cnt:ContentAsText", "dctypes:Text"], 
        "chars": "This is part of our logo"
    }, 
    "hasTarget": {
        "@id": "urn:uuid:cc2c8f08-3597-4d73-a529-1c5fed58268b", 
        "@type": "oa:SpecificResource", 
        "hasSelector": {
            "@id": "urn:uuid:7978fa7b-3e03-47e2-89d8-fa39d1280765", 
            "@type": "oa:FragmentSelector", 
            "conformsTo": "http://www.w3.org/TR/media-frags/", 
            "value": "xywh=10,10,5,5"
        }, 
        "hasSource": {
            "@id": "http://www.example.org/images/logo.jpg", 
            "@type": "dctypes:Image"
        }
    }
}
図5.1.3. 詳細なOpen Annotation シリアライゼーション

リソースの埋め込み

Open Annotation コアは 文字列の本体（Body）を埋め込む方法について説明している。しかし、表現が利用可能であることを確認するためにセレクタ（Selector）、スタイル（Style）、可能性としてはターゲット（Target）までもに埋め込むことが有用であることがしばしばある。

Webアーキテクチャは、すべてのリソースがURIを持っていることを前提とし、さらにそれらがHTTP URIからの検索で利用可能であることが期待されている。しかし、一部のクライアントは、アノテーション処理の一部として作成されるリソース全てに対してデリファレンス可能なURIを自分で生成できないかもしれない。これは本体（Body）、指定子（Spcifier）、スタイル（Style）やその他ユーザーが生成した情報を含むだけでなく、それがオンラインで利用可能でない場合は、可能性としてターゲット（Target）を含む。

オンライン上にあり、デリファレンス可能なリソースと埋め込まれたリソースの両方を丁寧かつ一貫して扱うモデルを持つことが重要である。両方のケースでは、「埋め込まれたテキスト形式の本体（Body）」セクションにあるように、コンテンツは単なる文字列リテラルとして使用されるだけはなく、リソースとして表現される。どちらの場合も、バイナリデータを含む全てのコンテンツタイプを処理しなければならないし、Open Annotationモデル内のリソースの全てのクラス（ Body、Target、Style、Selector、State）を処理しなければならない。

Open Annotationモデルは、アノテーション（Annotation）グラフ内のそのようなリソースを直接含めるために、"Representing Content in RDF"の仕様を使用する。リソースは、解決できないURNと、cnt:ContentAsTextや cnt:ContentAsBase64 のように"Representing Content in RDF"の仕様にあるような適切なクラスを割り当てられるべきである（SHOULD）。リソースの識別が重要ではないと考えられる場合は、RDFの空白ノードをURNの代わりに使用してもよい（MAY）。

アノテーション（Annotation）の中のRDFグラフのシリアライゼーションを埋め込む方法については 「RDFグラフの埋め込み」 を参照すること。

モデル

語彙項目タイプ説明
cnt:ContentAsTextClassリソースの表現は、プレーンテキストとして表現。
cnt:ContentAsBase64Classリソースの表現は、Base64エンコードされたテキストとして表現。
cnt:charsProperty表現を格納するContextAsTextのプロパティ。
１個のContentAsText リソースに対してきっちり1個のcnt:charsプロパティがなくてはならない（MUST）。
cnt:bytesProperty表現を格納するContentAsBase64のプロパティ。
１個のContentAsBase64リソースに対してきっちり1個のcnt:byteプロパティがなくてはならない（MUST）。
cnt:characterEncodingPropertycnt:charsプロパティもしくはcnt:bytesプロパティのコンテンツの文字列の文字コードエンコーディング。
１個のContentAsTextもしくは ContentAsBase64リソースに対してきっちり1個のcnt:characterEncoding プロパティがあるべできある（SHOULD）。
dc:formatProperty表現のメディアタイプ。
埋め込まれたリソースごとにきっちり１個ののdc:formatプロパティがあるべきである（SHOULD）。

図 5.2. リソースの埋め込み 
<anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
    oa:hasTarget <sptarget1> ;
    oa:styledBy <style1> .

   <style1> a oa:CssStyle, cnt:ContentAsText ;
    cnt:characterEncoding "utf-8" ;
    cnt:chars ".red { color : red }" .

   <sptarget1> a oa:SpecificResource ;
     oa:hasSource <source1> ;
     oa:styleClass "red" .

使用

クエリ：埋め込まれたCSSスタイルを持つアノテーションを検索。
 SELECT ?anno WHERE { ?anno oa:styledBy ?style . ?style a oa:CssStyle .
    ?style a cnt:ContentAsText } 
=> <anno1>

さらなる例はこちらを参照すること。

RDFグラフの埋め込み

アノテーション（Annotation）の中にリソースを埋め込むこと１つの特定のケースは、RDFグラフとして表現されたステートメントを埋め込むことである。トリプルは著作者と由来が区別できる状態でなければならないため、リソースを構成するトリプルをアノテーション（Annotation）グラフに単純にいれてはならない（MUST NOT）。そうでない場合、本体（Body）グラフやターゲット（Target）グラフのメタデータと識別子はアノテーション（Annotation）グラフの中で消失されたまま、組み込まれてしまうだろう。

最も簡単な方法は、をデリファレンス可能な HTTP URIを持つその他のリソースとしてグラフを公開し、アノテーション（Annotation）でこのURIを参照することである。この方法を推奨する（RECOMMENDED）。

単一のドキュメントが要求され、グラフをアノテーション（Annotation）の中に埋め込まれなければならない場合には、２つの方法をとることが可能である。

  1. 前のセクションで説明したように、グラフのシリアライゼーションに、"Content in RDF"を使用して埋めこんでもよい（MAY）。リソースは、dc:formatのメディアタイプとtrig:Graphで与えられたクラスのように、リソースを使用するアプリケーションに表現がグラフであることを決定するに必要な適切なメタデータを持たなければならない（MUST）。
  2. 別の方法として、クライアントが名前付きグラフを処理できることを明確にするような方法でアノテーション（Annotation）が要求された場合は、アノテーション（Annotation）をTrigやTrixのように名前付きグラフを使用して表現してよい（MAY）。リクエストは、HTTPのContent Negotiation機能を使用するか、サーバがTrig/Trixシリアライゼーションのために別のURIを提供してもよい。この制限は、シリアアライゼーションを解析できず、故にアノテーテーション（Annotation）を全く処理できないクライアントとの相互運用性を確保するためである。この方法は、以下の図5.3.に示されるとおりである。

モデル

語彙項目タイプ説明
trig:GraphClass名前付きグラフのクラス

図5.3.名前付きグラフのシリアライゼーション 
 {
 <anno1> a oa:Annotation ;
      oa:hasBody :graph1 ;
      oa:hasTarget <target1> .

    :graph1 a trg:Graph .
  }
    
  :graph1 { 
    <target1> relationship <thing1> . 
  }

NB.この図はTurtleではなく、Trig形式が使用されている。

使用

クエリ：ターゲット（target）に関する関係を表現する本体（body）を持つアノテーションを全て検索。
 SELECT ?anno, ?what WHERE { ?anno oa:hasBody ?g . ?anno oa:hasTarget ?t .
           GRAPH ?g { ?t relationship ?what } }
  }
=> <anno1>, <thing1>

さらなる例はこちらを参照すること。

リソースの等価性

アノテーション（Annotation）に固有の課題ではないが、システム間でシンジケート化されるリソースを取り除くことは、複数の複製物かとても近い派生物の間の等価性を表現することによって、大いに減らすことができる。重複したアノテーション（Annotation）を発見することができなかったシステムは、単純にもそれらのすべてを提供してしまい、とてもよくない経験を提供しまうことになる。統計を生成するシステム、評価モデル、アノテーションのためのスパムフィルタリング、またはそれに類似するシステムも、この能力を持たずにとてもよくない結果を生むことになるだろう。これらの要件を考えると、Open Annotationモデルには、2つのリソースが必ずしも完全に同一ではないとはいえ、等価であり、故に分けて維持及び処理されるべきではない主張する関係が含まれている。

システムがあるアノテーション（Annotation）を取得し、別のHTTP URIでそれを再発行した場合には、オリジナルのアノテーション（Annotation）と再発行されたアノテーション（Annotation）の関係をoa:equivalentToで表現するべきである（SHOULD）。oa:equivalentTo関係を追加することでグラフが変化した時、システムはoa:serializedAtとoa:serializedByプロパティを更新するべきである（SHOULD）。

埋め込まれたリソースも、独自のHTTP URIで再発行された時には同様に扱われるべきである（SHOULD）。システムが新しいHTTP URIで埋め込 ​​まれたリソースを公開する場合、それはリソースのURNと利用可能な新しいURIの間のoa:equivalentTo関係を表現するべきである（SHOULD）。埋め込 ​​まれたリソースは空白ノードとして伝達されている場合は、RDF Concepts 1.1に記載されたスコーレム化（Skolemization）の手法を使用するべきである（SHOULD）。このシステムはその裁量により、グラフから埋め込まれたリソースを削除してもよく（MAY）、デリファレンス可能なURIから参照してもよい（MAY）。これが発生すると、アノテーション（Annotation）グラフは等価性を維持しつつ、最初のバージョンから再発行した状態へ変化することが可能になる。

Model

語彙項目タイプ説明
oa:equivalentToRelationship[prov:alternateOfのサブプロパティ]oa:equivalentToの関係のサブジェクトとオブジェクトリソースは、同じリソースを表現する。しかし、oa:serializedBy、oa:serializedAt のような異なるメタデータ、異なるシリアライゼーションフォーマットをもつ可能性がある。oa:equivalentToは対照的で推移的な関係である。もしA oa:equivalentTo Bであるならば、B oa:equivalentTo Aも真である。B oa:equivalentTo Cであるならば、A oa:equivalentTo Cも真である。
アノテーション（Annotation）は、アノテーション（Annotation）の複製物もしくは他のリソースのoa:equivalentTo関係の0個以上のインスタンスを含んでもよい（MAY）。また、利用可能な数だけ含めるべきである（SHOULD）。

図5.4.リソースの等価性 
<anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
    oa:hasTarget <target1> ;
    oa:serializedAt "2012-12-12T12:12:12Z" ;
    oa:equivalentTo <anno2> .
    
  <anno2> oa:serializedAt "2013-01-28T20:00:00Z" .

使用

クエリ：特定のアノテーションと等価であるアノテーションを検索。
 SELECT ?anno WHERE { <Anno1> a oa:Annotation ; oa:equivalentTo ?anno }
=> <anno2>

さらなる例はこちらを参照すること。

前のページ   目次   次のページ