SHACL入門 ― RDFの「形」を検証する

別バージョン

ナレーション解説

章立て

1. 1

   本編

   データの形のバラつき・シェイプで検証(SHACL)・ノード/プロパティシェイプ・制約・検証レポート・ShEx(Wikidata EntitySchemas)・SPARQLやXMLスキーマとの関係・始め方

   読み上げ原稿

   • 0:00RDFの「形」を検証する

     皆さん、こんにちは。この動画は、デジタル人文学入門 技術要素シリーズ、なかむらさとるの解説回です。この回のナレーションは合成音声でお届けします。テーマはSHACLです。RDFでデータをつなぎ、SPARQLで引き出す。その先で、書いたデータが期待した形になっているかを検証する。その考え方を初学者向けに、図を交えながらゆっくり見ていきます。プログラミングの予備知識はなくても大丈夫です。どうぞ気楽について来てください。

     
   • 0:40この動画について

     はじめに、この動画について簡単にご案内します。この動画は、クリエイティブ・コモンズ(CC)の方針のもとで独自に構成した解説です。今回の題材はよいシーシー教材が少ないため、仕様などで事実確認した上で新規に作っています。スライドと図は新規に作成し、ナレーションはAIの合成音声でつくっています。なお、この回の声はいつもの中村本人のクローン声ではありません。あくまで実験的な取り組みですので、内容はご確認・ご注意のうえご利用ください。誤りに気づかれたら概要欄からご指摘ください。出典とライセンスは最後と概要欄にまとめてあります。それでは本編に入りましょう。

     
   • 1:32この回のゴール

     まず、この回のゴールです。目標は大きく四つ。一つめは、SHACLがRDFをシェイプ、つまり期待する形で検証する仕組みだと説明できること。二つめは、ノードシェイプとプロパティシェイプ、そして個数・型・クラスといった主な制約を説明できること。三つめは、検証が適合か違反かのレポートを返すと説明できること。そして四つめは、もう一つの道シェクスと、デジタル人文学での使いどころを知ることです。RDFやSPARQLの回を見ているとつながりやすいですが、必須ではありません。

     
   • 2:16今日の流れ

     今日の流れです。はじめに、なぜ検証が要るのかを、データの形のバラつきから見ます。つぎに、シェイプで検証するSHACL。それから、もう一つの道シェクス。そして、問い合わせやXMLのスキーマとの位置づけ。最後に、使いどころと始め方を紹介します。

     
   • 2:41なぜ「検証」が要るのか

     それでは、はじめましょう。まずは、なぜ検証が要るのか。データの形がバラつくという、ところから見ていきます。

     
   • 2:52RDF＝三つ組が重なった「網」

     図を見てください。前の回で見たように、RDFは主語・述語・目的語の三つ組を重ねた、網のようなグラフでした。ホメロスを中心に、生まれた場所や時期が線でつながっています。私たちがこれから検証するのは、この、できあがったデータの形です。

     
   • 3:15データの「形」はバラつく

     ところが、データはいつもきれいに揃っているとは限りません。図を見てください。上のホメロスは、生まれた場所がイオニアという場所になっていて問題ありません。ところが、下のサッフォーは、生まれた場所が紀元前七世紀という日付になっています。これは場所ではありません。型がちがう。ほかにも、必須のはずの項目がそもそも無い、ということも起こります。一件なら気づきますが、大量のデータでは、こうした形のバラつきになかなか気づけません。

     
   • 3:53「期待する形」を決めて照らしたい

     そこで、どうするか。データに期待する形、つまりルールをあらかじめ決めておき、それに合っているかを機械的に照らし合わせたい。一件ずつ手で確かめるのは、大量データでは無理だからです。このシェイプによる検証を担うのがSHACLです。正式には、シェイプス・コンストレイント・ランゲージ。形の制約の言語、という意味の、W3Cの標準です。

     
   • 4:25シェイプで検証する ― SHACL

     では、そのSHACLでどう検証するのか。シェイプの書き方から見ていきます。

     
   • 4:32シェイプ＝期待する「形」の宣言

     図を見てください。シェイプとは、データに期待する形を宣言した、テンプレートのようなものです。たとえばパーソン、人物に対して、こういう形であってほしいと決めます。検証の対象を決める部分をノードシェイプ。そして、生まれた場所は一つ以上あって、それは場所であること、というように項目ごとに縛る部分をプロパティシェイプと呼びます。

     
   • 5:01書き方（SHACL／Turtle）

     実際の書き方を見てみましょう。図の例はTurtleという、RDFの記法です。パーソンシェイプはノードシェイプであり、対象はパーソン。そしてプロパティとして、パス、つまり対象の述語が生まれた場所で、ミニマムカウントが一、クラスが場所。言葉にすると、パーソンは生まれた場所を一つ以上持ち、それは場所であること。これを宣言しているわけです。

     
   • 5:32いろいろな制約を組み合わせる

     制約はこれ以外にもいろいろあり、組み合わせて使います。個数の下限や上限。データの型、たとえば文字列か日付か数か。クラス、たとえば場所であること。さらに、あたいの範囲や書式、たとえば正規表現でのパターン。こうした制約を積み重ねることで、データに期待する形を細かく表現できます。

     
   • 6:00検証すると「レポート」が返る

     では、シェイプをデータに当てるとどうなるか。図を見てください。RDFのデータをSHACLで検証すると、結果が検証レポートとして返ってきます。ホメロスは形に合っているので適合。サッフォーは、生まれた場所が場所ではないので違反。しかも、ただダメと言うのではなく、どのノードがなぜ違反なのか、という理由まで、機械が読める形で返してくれます。

     
   • 6:30ここまでのポイント

     ここで、いったん整理します。SHACLは、RDFをシェイプ、つまり期待する形で検証する仕組みでした。ノードシェイプで対象を、プロパティシェイプで各項目を縛り、個数・型・クラスなどの制約を組み合わせる。検証は、適合か違反かを理由つきのレポートで返す。これが基本です。じつは、SHACLとよく似た、もう一つのシェイプ言語があります。シェクスです。

     
   • 7:04もう一つの道 ― ShEx

     ここからは、もう一つの道シェクスを見ていきます。

     
   • 7:08ShEx＝別の書き味のシェイプ言語

     シェクスは、シェイプ・エクスプレッションズ。シェイプの表現、という言葉から来ています。図のように、同じ期待する形を、より文法的に簡潔に書くのが特徴です。たとえば、パーソンシェイプは生まれた場所を一つ以上持ち、それはプレイスシェイプである、というように書きます。プラスの記号が一つ以上を表しています。中身の考え方はSHACLと同じです。

     
   • 7:39例：Wikidata の EntitySchemas

     シェクスがよく使われている実例が、Wikidataです。Wikidataでは、シェクスで、このクラスはこういう形であるべき、というスキーマを共有しています。これをEntitySchemasと呼びます。たとえば、人物なら生年や職業を持つ、といった期待する形をみんなで合意できる。コミュニティでデータの質をそろえる、実践的な使い方です。

     
   • 8:07SHACL と ShEx の使い分け

     では、SHACLとシェクス、どちらを使えばよいのでしょう。どちらもシェイプで形を検証する、という目的は同じです。SHACLはW3Cの標準で、RDFそのもので書け、ツールや拡張が豊富です。シェクスは文法的で簡潔で、Wikidataなどコミュニティでの採用が厚い。迷ったら、まわりのエコシステムに合わせて選べばよいでしょう。対立ではなく、同じ問題への二つの道です。

     
   • 8:41位置づけ・使いどころ

     ここからは、この検証という技術の位置づけを整理します。

     
   • 8:47「検証」と「問い合わせ」は別もの

     まず、よく混同されるSPARQLとの違いです。SPARQLは、条件に合うデータを取り出す問い合わせでした。これに対してSHACLは、データが期待した形かどうかを判定する検証です。取り出すのか、形を保証するのか。目的が違います。なお、SHACLは内部でSPARQLを使う書き方もできますが、役割は別ものと捉えてください。

     
   • 9:16XMLのスキーマに当たる層

     もう一つ、XMLの世界と並べると分かりやすくなります。図を見てください。XMLには、エックスエスディーやアールエヌジー、Schematronといったスキーマで、文書の妥当性を検証する仕組みがあります。RDFにおけるSHACLやシェクスは、ちょうどこれに当たる層です。XMLにスキーマがあるように、RDFにはシェイプ言語がある。そう捉えると掴みやすいでしょう。

     
   • 9:48考えてみよう

     ここで、少し立ち止まって考えてみましょう。あなたが扱っているデータに課したい形、つまりルールは、どんなものでしょうか。この項目は必須、ここは日付、このあたいはこの範囲。よろしければ、ここで一度動画を止めて思い浮かべてみてください。

     
   • 10:10ここまでのポイント

     ここまでを整理します。シェクスも、同じシェイプによる検証を別の書き味で実現するものでした。SHACLは標準で拡張が豊富、シェクスはコミュニティ採用が厚い。検証は問い合わせとは目的が違い、XMLのスキーマに当たる、RDFの形の保証の層でした。

     
   • 10:33DHでの活用

     デジタル人文学でも、この検証は役に立ちます。文化遺産のリンクトデータを公開する前に、データの形をまとめて点検する。機関どうしでシェイプを、データの約束ごととして共有する。WikidataのEntitySchemasで、クラスの期待形をそろえる。さらに、データの処理の流れに検証を組み込んでおけば、壊れたデータを早い段階で見つけられます。

     
   • 11:03おさえておきたい前提

     一つ、おさえておきたい前提があります。RDFは、オープンワールド、つまり開かれた世界を前提とします。これは、書かれていないことがただちに偽であるわけではない、という考え方です。ですから、この項目は必須、といった形は、シェイプではっきり明示してはじめて検証できます。そして、検証はあくまでデータに書かれている範囲での判定です。まずは一つの必須項目から、シェイプを少しずつ足していくのがおすすめです。

     
   • 11:40始め方・学ぶには

     では、自分でも試したいと思ったら、どうすればよいでしょう。まず触れてみるなら、SHACL PlaygroundやRDFShapeといったブラウザ上のツールで、データとシェイプを入れて検証を試すのがよい入り口です。プログラムなら、pySHACLやApache Jenaなどがあります。そして正式な定義は、W3CのSHACL勧告で確認できます。コツは、一つの必須プロパティのシェイプから、小さく育てていくことです。

     
   • 12:14まとめ

     今日のまとめです。SHACLは、RDFをシェイプ、つまり期待する形で検証する仕組みでした。ノードシェイプとプロパティシェイプに、個数・型・クラスなどの制約を書き、検証は適合か違反かを理由つきのレポートで返す。別の道に、シェクスがありました。RDFを書いて、問い合わせて、そして検証する。データの質をそろえる最後の一手として、つかんでいただけたならと思います。

     
   • 12:48出典・ライセンス

     本動画の、スライド、図、ナレーション原稿は、クリエイティブ・コモンズ(CC)の表示ライセンス、シーシー・バイ・四点ゼロで公開します。出典表示のうえ、自由に再利用いただけます。内容は、W3CのSHACL勧告などで事実確認しており、これらの仕様や書籍は参照のみで、翻案はしていません。図と文は、すべて新規に作成したものです。

     
   • 13:19ご清聴ありがとうございました

     以上で、SHACLの入門を終わります。RDFが期待した形になっているかを検証する。その第一歩をつかんでいただけたならと思います。ご清聴、ありがとうございました。