1 RDFの語彙とレコード記述の規則

2 RDFの語彙とは

• RDFの語と語彙
  • 語（term）：リソースの関係（プロパティ）とリソースのグループ（クラス）にURIで名前付けしたもの
  • 語彙（vocabulary）：関連する語をまとめて定義したもので、通常、語のローカル名の前に共通の部分URIを持つ
  • 語彙の共通部分URIは、しばしば名前空間URIと呼ばれる
• RDF SchemaとOWLによる語彙記述
  • RDF Schema：RDFのプロパティについて、階層構造およびクラスとの関係（定義域、値域）を記述。クラスは階層が記述できる
  • OWL：クラス表現（列挙、プロパティ制約、クラス和／積／否定）の組合せでクラス公理を記述。プロパティ値の範囲、出現回数をクラスによって使い分けられる。プロパティの論理性質（データ型、関数型など）も記述できる
  • いずれも開世界（すべての知識を既知とすることはできない）を前提とする。値域やプロパティ制約の情報は、推論（明示されていない情報を規則から導く）に用いられる

3 RDF/OWLの前提と「規則」の表現

• RDFは開世界仮説（OWA）を前提としている
  • 対象世界はオープンで、すべての情報を知ることはできず、常に未知の情報がある
  • 本にはcreatorが少なくとも1人いるObjectMinCardinality( 1 dcterms:creator )とするとき、
  • ある本のレコードにcreatorがない→どこか別のグラフに情報がある（エラーではない）
• RDFは唯一名仮説（UNA）を前提としない
  • 同一の実体が複数のURIで識別されることがある（URIが異なるだけでは別の実体とは断定できない）
    • たとえばある人物はWeb NDLAのURIでもORCID IDでも識別できる
  • 本のfirstAuthorは1人だけObjectCardinality( 1 ex:firstAuthor )であるとき、

  • <http://iss.ndl.go.jp/books/R100000002-I000007614821-00>
      ex:firstAuthor <http://id.ndl.go.jp/auth/entity/00797230> ; #あるグラフAから
      ex:firstAuthor <http://orcid.org/0000-0003-2953-7963> ; ... #別のグラフBから

  • →2つのURIは同一の人物を指している（ex:firstAuthorが2回出現してもエラーではない）
• RDF/OWLの表現は推論規則
  • 明示されない情報を論理的帰結として導く
  • 検証のための規則ではない

4 アプリケーション・プロファイル

• DCアプリケーション・プロファイル
  • 内部システムで情報を扱うためには、語彙（RDBのフィールド名など）とその制約（データ型、必須など）を合わせてスキーマ定義
  • 公開システムの情報記述には、既存語彙を再利用するほうがデータの相互運用性が高まる
  • →スキーマ定義を、既存（＋独自）語彙と応用（アプリケーション）毎の制約記述に分離
  • DCMIのシンガポール・フレームワークで枠組みを整理
  • 

5 記述規則とスキーマレジストリ

• 記述規則（構造的制約）の表現
  • 何を（対象クラス）記述するために、どのプロパティを、どのような約束で用いるか（構造的制約）
  • 例：本（Book）には著者（creator）が1人以上いて、その値は行為者（Agent）である
• 記述セットプロファイル（DSP）
  • DCアプリケーション・プロファイル定義における構造的制約記述
  • 構造的制約を機械可読な形で記述する（DCMI-DSPの詳細は後述）
• メタデータスキーマレジストリ
  • 語彙と記述規則を合わせた「メタデータスキーマ」を登録し、スキーマの共有や再利用を図る
  • スキーマを用いてデータの入力支援や変換を行なう
  • データが設計者の意図どおりになっているかをスキーマに照らして確認する（検証）
  • メタデータ情報基盤のMetaBridge

6 簡易記述セットプロファイル

• 簡単なテーブルによる記述セットプロファイル
  • データ記述の約束は表形式で定義されることが多い
  • 簡易DSP：表の書き方を標準化することで、記述セットプロファイルをコンパクトに表現（メタデータ情報共有ガイドラインの簡易DSPファイルの記述方法参照）

  • 項目規則名	プロパティ／クラス	最小	最大	値タイプ	値制約	説明
    書誌ID	ex:Book			ID		本のID
    タイトル	dcterms:title	1	1	文字列		本のタイトル
    著者	dcterms:creator	1	-	参照値	foaf:Agent	本の作者。URIで示す
    出版者	dcterms:publisher	0	-	構造化	#Publisher	本の出版者。構造化して示す

  • 項目規則名にはデータのヘッダ（項目ラベル）を対応付け、変換のキーに利用できる
  • 値タイプがIDである項目は主キーに相当。この場合のみ2列目はこのリソースのクラスを示す（それ以外はプロパティ）
  • 値制約はデータ型や値域に相当。値タイプが構造化である場合、値制約として同じファイル内の別の記述規則を参照できる
  • MetaBridgeの登録にも簡易DSPを利用できる（記述規則登録チュートリアル参照）

7 DCMIの記述セットプロファイル

• メタデータを記述するレコードの集合としての記述セット
  • 記述セットプロファイル＝記述テンプレートの集合
  • 記述テンプレート（Description Template）：ひとつのリソースを記述するための項目文の集合を示し、対象リソースに関する制約を表現する
  • 項目文テンプレート（Statement Template）：1つの属性（プロパティ）に適用される制約を表現する
• DCMI-DSP草案
  • 2008年に草案を公開。テンプレートの構造が示され、XML（および部分的にRDFで）の構文ひな形が提示されている
  • XMLとDC抽象モデル（DCAM）を念頭に置いているため、入れ子表現が前提で、RDF/OWLとは用語法や一部概念が異なる
    • たとえばOWLのデータ型プロパティがLiteralStatementTemplate、オブジェクトプロパティがNonLiteralStatementTemplateなど
• DCMI RDF Application Profiles Task Group
  • リンクするデータを念頭に置いたアプリケーション・プロファイルのあり方を検討するために2014年6月に設立
  • DCMI-DSPをRDFとして考えなおすための分析。適切なデフォルト値を用意、項目文テンプレートにURIを与えられるようになど
    • DSPの背景と新たな位置付けに関するTom Bakerによるプレゼンテーション（PDF）
  • 後述する他のRDF検証手法／活動との連携

8 DCMI-DSPの記述

• 記述テンプレート
  • リソースが属するクラスをdsp:resourceClassで、リソース記述に用いる項目文テンプレートをdsp:statementTemplateで示す

  • <#Book_description>
        a dsp:DescriptionTemplate ;
        dsp:resourceClass ex:Book ;
        dsp:statementTemplate .... #次の項目文テンプレート表現が続く

• 項目文テンプレート
  • プロパティをdsp:property、出現回数制約をdsp:minOccur、dsp:maxOccurで示す
  • 値制約表現をdsp:nonLiteralConstraintなどで関連付ける。制約はDCAM的な表現

  • [    a dsp:LiteralStatementTemplate ;
         dsp:property dcterms:title ;
         dsp:minOccur 1 ;  dsp:maxOccur 1 ;
         # データ型、言語タグなどの値制約があれば dsp:literalConstraint [...]
    ], [ a dsp:NonLiteralStatementTemplate ;
         dsp:property dcterms:creator ;
         dsp:minOccur 1 ;  dsp:maxOccur "infinity" ;
         dsp:nonLiteralConstraint [
             dsp:valueClass foaf:Agent ;
             dsp:valueURIOccurrence "mandatory"  ] ] 

9 RDFデータの検証

10 RDFデータの品質とグラフの検証

• 公開データの共有と品質問題
  • 入力ミス、担当者の理解差などにより、データセット内の値が不揃いだったり欠落したり
  • 複数ソースのグラフを集約する場合、データセット毎に品質が異なる
  • 
  • 入力ミスを防ぐために、構造制約を利用して入力補助やチェックを行なうUIを提供したい
  • 共有・再利用のために、明示されたグラフの構造制約に基づく検証を行ないたい
• 複数のRDF制約表現・検証方法
  • XMLスキーマを定義してRDF/XMLを検証（特定の構文に限定して検証）
  • SPARQLを用いた不整合の発見
  • RDFスキーマ、OWLのプロパティ制約公理を、前提を変えて利用
  • SPIN、Resource Shape、Shape Expressionなどの制約検証記述

11 SPARQLによる不整合発見

• 制約規則をSPARQLのトリプルパターンとして表現
  • 「タイトル（dcterms:title）は文字列で、必ず1回だけ出現」にマッチするものを調べる

  • SELECT * WHERE {
        ?s dcterms:title ?o .
        FILTER (isLiteral(?o))
    } GROUP BY ?s HAVING (count(*)=1)

  • 制約に反するパターンを調べるためには、例えばMINUSを用いる

  • SELECT * WHERE {
        {?s ?p ?o} MINUS {
            SELECT ?s WHERE {
                ?s dcterms:title ?o .
                FILTER (isLiteral(?o))
            } GROUP BY ?s HAVING (COUNT(*)=1)
        }
    }

  • CONSTRUCT句を利用すれば、エラーの説明などを加えて返すことも可能

12 ICV：OWLクラス表現を利用した整合性検証

• 語彙定義とプロパティの値
  • RDFスキーマの値域＝プロパティの目的語が属するクラスの情報

  • dcterms:creator a rdf:Property ;
       rdfs:range foaf:Agent .

  • OWL2クラスのプロパティ制約表現

  • ex:Book a owl:Class ;                    #リソースの主語がこのクラスであるとき
       owl:equivalentClass [
          a owl:Restriction ;
          owl:onProperty dcterms:creator ; #このプロパティは
          owl:minQualifiedCardinality 1 ;  #少なくとも1回（出現回数制約）
          owl:onClass foaf:Agent           #目的語はこのクラス（データ型ならonDataRange）
       ] .

  • ただし前述のとおりこれらは「検証のための制約」ではない
• IC（Integrity Constraints）としてのOWL
  • RDFS/OWLの定義はそのままでは検証に利用できないが、
  • 前提を変えて、閉世界（データは全部揃っている）、唯一名（URIが異なれば別の実体）とみなせば、IC（整合性制約）として検証に使うこともできる。Stardogが実装

13 SPIN

• SPARQL Inferencing Notation (SPIN)
  • SPARQLを用いたルール、制約記述をクラス定義に結びつけて、インスタンスに期待されるものを形式表現する記法。TopBraidに実装され、2011年にW3C Member Submission

  • :Book a owl:Class ;
        spin:constraint [
            a sp:Construct ;  #ここでは結果をCONSTRUCTで示す
            sp:text """（主語を?thisとした検証SPARQLクエリ）""" ;
        ] .

• SPIN Template
  • SPARQLの対象プロパティなどを変数にし、汎用制約テンプレートとして再利用できる
  • 定義済み汎用テンプレートを用いれば、自分でSPARQLを書かなくてもよい。例えばspl:Attributeテンプレートでタイトルの制約を記述すると

  •     spin:constraint [
            a spl:Attribute ;
            spl:predicate dcterms:title ;
            spl:minCount 1 ; spl:maxCount 1 ;
            spl:valueType xsd:string ;
        ] ;

  • OWLのプロパティ制約表現やDSPに近い表現ができる

14 Resource Shape

• OSLCのウェブアプリ開発の統合ツール
  • OSLCで開発環境毎に異なるバグレポート、履歴管理、テストケースなどを統合する方法として策定。2014年2月にW3C Member Submission
  • RDFグラフの期待される構造を“シェイプ”として表現。SPINのテンプレート利用記述に似ている

  • :BookShape a rs:ResourceShape ;
        rs:property [
            rs:name "タイトル" ;
            rs:propertyDefinition dcterms:title ;
            rs:occurs rs:Exactly-one ;
            rs:valueType xsd:string ;
        ], [
            rs:name "著者" ;
            rs:propertyDefinition dcterms:creator ;
            rs:range foaf:Person ;     #rs:valueShapeでPersonのシェイプURIの指定も可
            rs:occurs rs:One-or-more ;
            rs:valueType rs:Resource ;
        ] .

  • OSLCのツールで実装されている
  • 意味論をSPARQLを用いて定義

15 Shape Expressions

• 簡潔な表記と柔軟性
  • “シェイプ”を簡潔に記述する構文（RELAX NGにおけるコンパクト記法のように）
  • 2014年6月にW3Cメンバー提案。概要はShape Expressions 1.0 Primer
  • start=<shape_uri>で処理の出発点となるシェイプのURIを記述
  • シェイプ名（URIもしくは空白ノード）に続けて、シェイプで用いる項目文規則を{}内に「プロパティ 値」の形で列挙
  • 出現回数：値に*（0回以上）、+（1回以上）、?（0もしくは1回）などを加える。値のみの場合は必ず1回
  • 値規則：データ型URI；(value1, value2...)の形で列挙；ex:~の形でex:名前空間に属する値；@<shape_uri>の形で別のシェイプ

  • start = <BookShape>
    <BookShape>  {
        dcterms:title xsd:string,
        dcterms:creator @<AgentShape> +
    }
    <AgentShape> {
        a (foaf:Agent), foaf:name xsd:string ?
    }

    • 検証中にアプリケーションが実行する処理（レポートなど）を %js{ return....}% のような形で記述することも可能
  • 検証デモページで実際にデータを検証してみたり、対応するSPARQLやResource Shapeの表現を確認できる

16 “シェイプ”表現の標準化

• RDF Data Shapes WG
  • 2013年のRDF Validation Workshopを受けて、2014年10月にRDF検証標準化のためのW3C作業部会として設立
  • ミッション：RDFグラフの構造的制約＝“シェイプ”を記述し、それを用いてデータを検証するための標準を策定
• 活動の現状と今後
  • 前述のICV、SPIN、Resource Shape、Shape Expressionといった制約表現の比較検討から出発
  • 現在、User StoriesやDCMI RDF APによる要件整理をもとに、ユースケースと要件定義のための議論中
  • 勧告予定：“シェイプ”を記述するRDF語彙、RDFグラフと関連付けるための（SPARQLを用いた）意味論、および人が読み書きしやすい非RDF簡略構文

17 RDF検証に向けて

• 標準化の見通し
  • Data Shapes WGの計画では2016年前半にW3C勧告（実際は…？）
  • RDF語彙策定にあたってどの記述法がベースになるかは、表現力、簡潔さ、実装との関係などで綱引きがあり、まだ微妙
  • 関連する課題としてはRDFグラフの正規化表現（同等性の比較やグラフの電子署名）
• 過渡期の対応
  • どの記述法がベースになっても、基本的な要素（項目文制約をプロパティ、出現数、値で記述）は大きな違いはない
  • 簡易DSPなどの表形式制約記述からResource ShapeやShExへの変換は容易。各構文での相互マッピングも進みつつある
  • 現状でも各実装を利用しての検証は可能。最終的な勧告の姿はまだ見通せないので、柔軟な形（表など）で規則を整えておき、必要に応じていずれかの表現に変換して利用するのがおそらく賢明