本体(Body)とターゲット(Target)の型付け

アノテーション（Annotation）に関係するリソースの一般的なコンテンツの種類（テキスト、イメージ、オーディオ、ビデオなど）に関する情報は、アプリケーションに有用である。これは、本体（Body）リソースとターゲット（Target）リソースの型付けを使用して表現される。それによってクライアントはメディアタイプの長いリストを管理することなく、リソースをレンダリングさせるかどうか、どのようにレンダリングさせるかを容易に決定することができる。たとえば、 HTML5ベースのクライアントは、ターゲット（Target）リソースが適切なsrc属性を用いた<img>要素を生成する画像という情報を全ての画像のメディアタイプリストを管理せずとも使用することができる。アノテーション（Annotation）の作成者は、本体（Body）やターゲット（Target）の正確なメディアタイプも知らなくてもよいが、少なくともこの一般的なクラスは提供できるべきである。

RDFクラスを用いてこの情報の表現する場合は、Dublin Core Types vocabulary の使用が推奨される（RECOMMENDED）。最も一般的なクラスが以下の表に一覧されているが、他のクラスを使用してもよい（MAY）。以下の表の定義はDCMIタイプのドキュメントを要約したものである。なお、文字情報を含む画像をdctypes:TextとしてエンコードすべきというDCMIのアドバイスは、クライアントがリソースをレンダリングのために解釈する助けにならないため、Open Annotationのコンテキストの中では推奨されない（NOT RECOMMENDED）ことには注意してほしい。

アノテーション（Annotation）の本体（Body）リソースとターゲット(Target)リソースと関係づけられた1つ以上のコンテンツベースのクラスがあるべきである（SHOULD）。

モデル

語彙項目	タイプ	説明
dctypes:Dataset	Class	定義された構造においてデータをエンコードされたリソースのクラス
dctypes:Image	Class	主に見られることを意図された画像リソースのためのクラス
dctypes:MovingImage	Class	音声の有無にかかわらずビデオリソースのクラス、
dctypes:Sound	Class	主に聞かれること意図されたリソースのクラス
dctypes:Text	Class	主に読まれること意図されたリソースのクラス

図2.1.1.本体(Body)とターゲット(Target)の型付け

 
<anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
      oa:hasTarget <target1> .

  <body1> a dctypes:Text .
  <target1> a dctypes:Image .

使用

 
 SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a dctypes:Text }
=> <anno1>

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

埋め込まれたテキスト形式の本体（Body）

テキスト形式の本体（Body）を表現するために文字列リテラルのプロパティを使用する上記のアノテーションシステムがある。しかし、 Open Annotation モデルは、非テキスト形式とその他のタイプのリソースとの一貫性を維持するためにW3Cの"Representing Content in RDF"の仕様を採用している。Content in RDF の仕様は、コンテンツを表現するためにcnt:ContentAsTextクラスのリソースとコンテンツの文字列そのものを保持するためにcnt:charsプロパティを導入している。

本体（Body）が識別子を持つことが重要であるなら、cnt:ContentAsTextリソースをUUID、URIで識別することが推奨される（RECOMMENDED）が、他のURIが使用されてもよい（MAY）。例えば、短い個人的なメモへの使用など、識別子を持つことが重要であると考えられていない場合は、代わりにRDF 空白ノードを使用するべきである（SHOULD）。このパターンは、必ずしも識別子を持たせる必要がない場合の識別子の発行と維持の負担を減らすことになる。しかし、さらなアノテーション（Annotation）やその他のシステムから本体（Body）へ参照することが スコーレムIRIなしでは不可能となる。

例えば、プレーンテキスト内に埋め込まれたコメントとHTML内でエンコードされたものを区別するため、既知の場合は、 本体（body）のmedia typeはdc:formatプロパティを使用されたものをであるべきである（SHOULD）。プレーンテキスト以外のコンテンツを持つリソースをエンコードするように、cnt:ContentAsTextのその他の使用がありうるため、上記のように、dctypes:Text クラスは、cnt:ContentAsTextクラスといっしょに割り当てられてもよい（MAY）。

次の理由により、本体（Body）としてリテラルを直接持つモデルとして、このモデルが選ばれた。

• 本体（Body）やターゲット（Target）としてどのようなリソースも認めるその他のモデルとは整合性がとれないであろう。それ故、本体（Body）の中にテキストがあることは特別なケースとなるだろう。
• 広範囲なリテラルまたはリソースを持つ際にOWL-DLの単一のプロパティを表現することは不可能ではない。そして、これは推論及び他のシステムとの統合の上で重要であると考えられる。
• 本体（Body）の型をいつも決めなければならなくなると、JSON-LDによるシリアライゼーションと実装がより複雑になる。
• RDFにおいて、リテラルは彼らの言語とそれらと関係づけられたデータタイプを持つことができる一方で、リテラルと関係づけることができないという解釈にとって重要なテキストの他の側面がある。例として、メディアタイプ （text/plain 対 text/html）、方向性 （right-to-left 対 left-to-right）、エンコーディング(utf-8 対 ascii)、加えて、当然であるが、著作者、作成日などのようなメタデータが挙げられる。
• 以上の点を考慮すると、埋め込まれたテキスト形式の本体（Body）をエンコードできることがリソースにとって不可欠である。空白ノードを使用するコストが最小であるために、コンテンツを埋め込むための単一のメソッドの一貫性は、時折リテラルを使用できるオプションよりもさらに重要であると考えられる。
• 次のセクションで述べるように、テキスト形式のタグを一般的なコメントと区別できることが重要である。これは単なるリテラルでは可能ではないでだろう。

モデル

語彙項目	タイプ	説明
cnt:ContentAsText	Class	アノテーション（Annotation）の中にテキスト形式のリソースを埋め込むために、本体（Body）に割り当てられたクラス。 このクラスは、本体（Body）に割り当てられるべきである（SHOULD）。しかし、必須であるcnt:chars属性の存在によって推測することができる。
cnt:chars	Property	コンテンツの文字列。 ContentAsTextと関係づけられたちょうど1個のcnt:charsプロパティがなくてはならない（MUST）。
dc:format	Property	コンテンツのメディアタイプ。 リソースと関係づけられたちょうど1個のdc:formatプロパティがあるべきである（SHOULD）。
dc:language	Property	コンテンツの言語（既知の場合）。 0個以上のdc:languageプロパティがあってもよい（MAY）。各言語はRFC 3066の定義に従って、言語タグとして表現されるべきである（SHOULD） 。

図2.1.2.埋め込まれたテキスト形式の本体（Body）

 
<anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
      oa:hasTarget <target1> .
    
  <body1> a cnt:ContentAsText, dctypes:Text ;
    cnt:chars "content" ;
    dc:format "text/plain" .

使用

 
 SELECT ?comment WHERE { ?anno oa:hasBody ?body . ?body a dctypes:Text ; cnt:chars ?comment }
=> "content"

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

タグとセマンティックタグ

短いテキスト文字列もしくはURIを伴うリソースのタグ付けは、アノテーション（Annotation）の一般的なユースケースである。タグは、一般的にキーワードやラベルであり、タグ付けされたリソースの組織化、説明、発見のために使用される。１つの言葉が複数の意味を持つという多義性の問題をさけるために、セマンティックウェブにおいては、URIが文字列に代替するものとして使用される。この状況では、川の"bank（土手）"と金融機関の"bank（銀行）"を参照するために、2つの異なるURLを使用するであろう。

Open Annotation コアモデルでは、タグはアノテーション（Annotation）の本体（Body）として表現さ​​れ、タグ付けされたリソースは、ターゲット（Target）として表現される。例えば、ある人はフランスの首都の画像に何が描かれているかを説明するために"paris"というテキスト形式のタグを関係づけることを望むかもしれない。同様に同じイメージに対し "capital"、"city"、"photo"、"stunning"がタグとして使用されるかもしれない。この状況は、前のセクションの「埋め込まれたテキスト形式の本体（Body）」 と同じ方法を用いてモデル化されている。アプリケーションは異なる方法でコメントやタグをレンダリングするため、本体（body）リソースもoa:Tagクラスが割りあてられるべきである（SHOULD）。以下の図2.1.3.1は、これを示している。

URIとして表現さ​​れるセマンティックタグにとって、本体（Body）はタグ付けされたリソースのURIである。上に挙げた例では、http://dbpedia.org/resource/ParisというURIを本体（Body）として代わりに使用した。通常は幅広く再利用されることを意図した統制語彙由来の用語である。このリソースは、検索され、ユーザーのためにレンダリングされてはならないことを知っておくことも必要である。そのため、oa:SemanticTagクラスは、タグ付けリソースに関係づけられなければならない（MUST）。セマンティックタグ及びその他のURIは、断片的な構成要素を持っている可能性があることによく注意する。その断片的な構成要素では、ドキュメントのセグメントを選ぶことが目的ではない。興味のあるセグメントを選択することを意味するため、これらのリソースはフラグメントセレクタ（Fragment Selector）を使用して再表現されてはならない（MUST NOT）。セマンティックタグ付けモデルは図2.1.3.2に示されている。

「動機（Motivation）」セクションで説明するように、アノテーション（Annotation）の理由をアプリケーションにより明確にわかるようにするために、テキストまたはセマンティックタグでタグ付けされたリソースにタグ付けするアノテーション（Annotation）はoa:taggingの動機（Motivation）も持つべきである（SHOULD）。そして、その他の動機（Motivation）も持っていてよい（MAY）。

他のアノテーション（Annotation）でoa:SemanticTagクラスの割り当てを継承した正規の本体（Body）として使用される可能性があるため、セマンティックタグとしてドキュメントのURIを使用することは推奨されない（NOT RECOMMENDED）。その代わりに、図2.1.3.3に示されているような、foaf:page述語を使用した新しいURIを作成し、ドキュメントにそのURIからリンクすることがより適切である。

モデル

語彙項目	タイプ	説明
oa:Tag	Class	埋め込みテキスト文字列のような、タグである場合に本体（Body）に割り当てられたクラス
oa:SemanticTag	Class	[oa:Tagクラスのサブクラス] セマンティックタグでタグ付けされたリソースである場合に本体（Body）に割り当てられたクラス。概念を識別するURIは、埋め込まれた文字列より統制語彙から用語由来の者であることが多い。
foaf:page	Relationship	foaf:page関係は、セマンティックタグと何らかの方法でタグ付けの概念を説明もしくは具現化したドキュメントの間を結ぶリンクを表現する。

図2.1.3.1.テキスト形式のタグ

 
 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasBody <tag1> ;
    oa:hasTarget <target1> .
    
  <tag1> a oa:Tag, cnt:ContentAsText ;
    cnt:chars "tag" .
  <target1> a dctypes:Image .

図2.1.3.2.セマンティックタグ

 
 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasBody <term1> ;
    oa:hasTarget <target1> ;

  <term1> a oa:SemanticTag .
  <target1> a dctypes:Image .

図2.1.3.3.セマンティックタグとドキュメントの参照

 
 <anno1> a oa:Annotation ;
    oa:motivatedBy oa:tagging ;
    oa:hasBody <term1> ;
    oa:hasTarget <target1> ;

  <term1> a oa:SemanticTag ;
    foaf:page <document1> .

  <target1> a dctypes:Image .

使用

 
 SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a oa:Tag }
=> <anno1>

本体(Body)またはターゲット(Target)を識別するフラグメントURI

アノテーション（Annotation）はリソース全体に対して（about）のものよりはリソースの一部に対して（about）のものが多い。リソースは任意の大きさにすることができ、アノテーションも関心に応じて任意にぴったりとした大きさにすることができる。"Architecture of the World Wide Web"では、リソースのセグメントは、リソースから興味のあるセグメントを抽出する方法の記述と抽出されたコンテンツの識別の両方を同時に行うフラグメントコンポーネントがついたURIを使用することで識別される。単純なアノテーションの場合には、本体（Body）もしくはターゲット（Target）のいずれかとしてこれらのフラグメントを使用できることが重要である。

リソースの一部を識別する目的のためにフラグメントURIを使用した結果と、実装上での場所にフラグメントURIを使用する制約に注意することが重要である。

• ほとんどのフラグメントは、個々のメディアタイプそれぞれで定義されている。全てのメディアタイプがフラグメントに関する仕様をもっているわけではない。
• メディアタイプがフラグメントの定義を持っている場合でも、十分かつ正確に目的のセグメントを記述することは可能ではないことがしばしばある。例えば、HTMLのフラグメントは、任意の範囲のテキストを記述するために使用することができない。
• 異なる仕様で定義された同じフラグメントの文字列が存在することがあり得るかもしれないため、メディアタイプが何であるかを知ることなしに何として識別されるのかを確信を持って決めることはできない。例えば、同じフラグメント文字列は、画像内の長方形のエリアもしくはHTMLドキュメントの名前付けされたセクションのいずれかを識別することができる。
• フラグメントURIは、セグメントを記述する他の方法、さらに特に本仕様の特定リソース（Specific Resource）モジュールで記述される方法との互換性がない。しかし、全てのシナリオにおいて、付加的レベルの記述が必ずしも必要とされるものではないと認識されている。
• URIは不明瞭な文字列であると考えられているため、フラグメントを無視してURLをで検索する場合、アノテーションシステムはフラグメントURIを持つアノテーションを発見しないかもしれない。例えば、ターゲット（Target）http://example.com/image.jpg#xywh=1,1,1,1を持つアノテーション（Annotation）は、http://example.com/image.jpgによる単純な検索では、たとえアノテーション（Annotation）がリソースの一部であるにも関わらず発見されないだろう。

これらの問題が懸念されない、または実装に大きな負担を与えるであろうシステムでは、フラグメントURIはアノテーション（Annotation）の本体（Body）もしくはターゲット（Target）として使用してもよい（MAY）。さもなければ、特定リソース（Specific Resource）モジュールで述べられているセレクタ（Selector）メカニズムを使用することを推奨する（RECOMMENDED）。セレクタ（Selector）はを既存の、そして、将来のフラグメントに係る仕様との互換性を保証するため移行メカニズム（ oa:FragmentSelector）を含んでいる。

モデル

図2.1.4.フラグメントURI

 
 <anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
    oa:hasTarget <t1#xywh> .

  <body1> a dctypes:Text .
  <t1#xywh> a dctypes:Image .

使用

 
 SELECT ?anno WHERE { ?anno oa:hasTarget <t1#xywh> }
=> <anno1>

 
 SELECT ?anno WHERE { ?anno oa:hasTarget ?x . FILTER ( regex (str(?x), "^t1")) }
=> <anno1>

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

本体（Body）なしのアノテーション（Annotation）

アノテーション（Annotation）が本体（Body）リソースを持っていない特別なケースが存在する。この種の状況の例としては、特定のリソースへのブックマーキング、リソース内のある箇所の指定、ハイライトする理由をコメントとして付さないリソースの1セクションへのハイライトがある。これらのアノテーション（Annotations）には、おそらくリソースの重要性やブックマークの理由について説明するために、本体（Body）が後になって追加されるかもしれない。

本体（Body）なしでアノテーション（Annotation）のために導入された新たな関係やクラスはない。

モデル

図2.1.5.本体（Body）なしのアノテーション（Annotation）

 
<anno1> a oa:Annotation ;
    oa:hasTarget <target1> .

使用

 
SELECT ?anno
  WHERE { ?anno oa:hasTarget <target1> .
    FILTER(NOT EXISTS { ?anno oa:hasBody ?notbody })
  } 
=> <anno1>

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

複数の本体(Body)とターゲット(Target)

前のセクションとは反対に、１つのアノテーション（Annotation）が複数の本体(Body) または/ 及び　ターゲット(Target）を持つ可能性もある。各本体（Body）は、ターゲット（Target）一式のセットとしてではなく、個々のターゲット（Target）に等しく関係づけられていると見なされる。本体（Body）またはターゲット（Target）がアノテーション（Annotation）を無効にするのでない限り、この構造は使用されるかもしれない。このため、以下の図1.1.5では、次の全てがそれぞれ真となる。

• body1は、target1について（about）である
• body1は、target2について（about）である
• body2は、target1について（about）である
• body2は、target2について（about）である

例としてのユースケースは、単一のターゲットイメージもしくはいくつかのウェブページに対する単一のコメントについて複数のタグを有するものが挙げられる。

あるコメントが複数のターゲット（Target）をそれぞれについて等しく個別にではなく、比較もしくは対比するように、複数の本体（Body）もしくはターゲット（Target）に対する異なるセマンティクスをアノテーション（Annotation）が必要とする状況では、「多重構造物」モジュールで説明されている追加の構造物を使用する必要がある。本体（Body）もしくはターゲット（Target）が順序づけられる、または、どのリソースがそのユーザーにとって最も適切であるかをクライアントに選択させることが可能である。

Open Annotation モデルは、複数の本体（Body）やターゲット（Target）を可能とする新しい関係を定義しない。oa:hasBody関係とoa:hasTarget関係が、分野として同じアノテーション（Annotaion）とともに複数回使用されている。

モデル

図2.1.6.複数の本体(Body)とターゲット(Target)

 
 <anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
    oa:hasBody <body2> ;
    oa:hasTarget <target1> ;
    oa:hasTarget <target2> .

使用

 
 SELECT ?anno WHERE { ?anno oa:hasTarget ?t1 ; oa:hasTarget ?t2 . 
    FILTER( ?t1 != ?t2 ) }
=> <anno1>

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

エージェント

このセクションでは、アノテーション（Annotation）に関係するエージェント、アノテーション（Annotation）を作成する者及びシリアライザに関する情報を記録するベストプラクティスを推奨する。

エージェントを解説するために下記の用語の使用が推奨される（RECOMMENDED）。FOAFの語彙からの他の語彙の使用も推奨される（RECOMMENDED）が、明示的には示されない。必要に応じて他の規定された語彙を使用してもよい（MAY）。FOAFはSoftwareAgentクラスを定義していない場合は、PROVクラスが使用される。prov:Agentとfoaf:Agentは同等のクラスである。

モデル

語彙項目	タイプ	説明
foaf:Person	Class	人間をエージェントとするものに対するクラスであり、一般的にはoa:annotatedBy関係のオブジェクトのクラスとして使用される。
prov:SoftwareAgent	Class	ソフトウェアをエージェントするものに対するクラスであり、一般的にはoa:serializedBy関係のオブジェクトのクラスとして使用される。また、OAのオブジェクトに使用される場合があります。機械生成されたアノテーションのannotatedBy。
foaf:Organization	Class	個人と対照する組織に対するクラス。例えば、oa:annotatedBy関係のオブジェクトのクラスとして使用されるかもしれない。
foaf:name	Property	エージェントの名前。 各エージェントは、ちょうど1個の nameプロパティを持つべきである（SHOULD）。
foaf:mbox	Relationship	エージェントと関係づけられたメールアドレス。mailto: URI スキームを使用する。 各エージェントは、1個以上のメールボックスを持ってもよい（MAY）。
foaf:openid	Relationship	エージェントに関係づけられているOpenIDのURI。 各エージェントは、1個以上のOpenIDを持ってもよい（MAY）。
foaf:homepage	Relationship	エージェントのホームページ。 各エージェントは、1個以上のホームページを持ってもよい（MAY）。

図2.2.1. エージェントモデル

 
 <anno1> a oa:Annotation ;
    oa:hasBody <body1> ;
    oa:hasTarget <target1> ;
    oa:annotatedBy <agent1> ;
    oa:serializedBy <agent2> .
  
  <agent1> a foaf:Person ;
    foaf:openid <OpenId1> ;
    foaf:name "A. Person" .
    
  <agent2> a prov:SoftwareAgent ;
    foaf:homepage <HomePage1> ;
    foaf:name "Code v2.1" .

使用

 
  SELECT ?anno WHERE { ?anno oa:annotatedBy ?who . ?who a foaf:Person }
=> <anno1>

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