rdflintによるLinkedOpenDataのCI運用イメージ
この記事は、CI/CD Advent Calendar 2019 の3日目の記事です。
CI/CD Advent Calendar 2019
https://qiita.com/advent-calendar/2019/ci-cd
Continuous Integration というと、
一般的にアプリケーションのテストやデプロイをイメージすると思いますが、
このエントリでは、データに対するテストにCIを活用する話題を取り上げます。
インターネットを通じて、データを公開する
Linked Open Dataの標準的な技術として、
RDF(Resource Description Framework)というデータ記述の枠組みがありますが。
私が中心となって開発したrdflintというツールを使うことで、
RDFのデータ記述をチェックする事が出来ます。
このエントリでは、rdflintによるCI運用イメージを紹介したいと思います。
imas/rdflint | GitHub
https://github.com/imas/rdflint
データの作成の全体像
複数人で、なんらかのデータを作成して公開する場合は、
次の図のように、
「追加・修正リクエストする人」
「チェックする人」
といった役割を分担して作業を行うことになるかと思います。
図では、
「データの追加・修正リクエスト」→「チェック」→「マスターデータ更新」→「サーバ反映」
という流れになっていますが。
実際には「マスターデータ更新」よりも前に、
サーバに反映したときに期待結果が得られるかを確認したいはずです。
このように望ましい形の流れでデータ更新を運用するためには。
「追加・修正リクエストする人」が自身で手元にサーバを構築して、
(特に、RDFのように決まった形式で、データを記述しなければならない場合)
追加・修正データをロードして、期待結果が得られるかを確認する事になります。
データを作る人がサーバ構築を行うのは手間である上に、
データ作成の担当者がサーバに詳しいとも限りません。
この問題を解消するための方法として、
ソフトウェアの開発で用いられるCIをデータ作成にも応用することが考えられます。
rdflintの概要
rdflintを利用することで、
LinkedOpenDataのデータ作成にCIを適用する事が出来ます。
rdflint自体は、
RDF形式で記述されたデータをチェックするコマンドラインツールです。
JVM上で動作するので主要なOSであれば利用できるかと思います。
いろいろな言語のlint系ツールと同じように、
CIの設定ファイルに起動コマンドを記載する事で利用できます。
具体的な設定方法は、以下の利用ガイドをご覧下さい。
RDFデータのチェックツール「rdflint」の利用ガイド
https://imas.github.io/rdflint/
rdflintによるデータチェックの考え方
次に、rdflintでは、どのような考え方でデータをチェックしているのかを紹介します。
大まかに言うと、rdflintでは以下の4段階でデータをチェックしています。
- 書式・文法が正しいか?
- データの不整合が無いか?
- 規定した制約に違反していないか?
- 統計的に見て外れている値が無いか?
書式・文法が正しいか?
rdflintでは、RDF形式のファイルをチェックしますが、
RDFファイルとして文法的に正しいか(=サーバにロード可能か?)をチェックします。
まず、このチェックでエラーとなるファイルは、
以降のチェックを行いません(パースできないので行えません)。
データの不整合が無いか?
データとして整合がとれていないものをチェックします。
RDF形式のデータは、有向グラフの構造なので、
bが定義されていない時に、a→bというedgeが存在する場合は、
整合がとれていません(リンク切れの状態)。
ファイルを文法的に解釈することは出来るが、
データとして整合がとれていないデータをチェックします。
規定した制約に違反していないか?
データの意味を考えた時に、
その値には、型の制約・定義域の制約などが存在する場合が多いです。
例えば「年齢」という属性値のデータを作成する場合は、
その値が「0以上」(定義域)の「整数」(型)であると言う制約があります。
このような制約を明示的に定義することで、データをチェックする事が出来ます。
制約の定義には、SHACLという標準を使用します。
Shapes Constraint Language (SHACL) | W3C
https://www.w3.org/TR/shacl/
統計的に見て外れている値が無いか?
先ほどはデータの意味を考えて、データの型や定義域の制約を定義しましたが、
ある程度の量のデータが存在する場合は、
明示的に制約を定義しなくても、データから制約を推定する事が出来ます。
例えば、「年齢」という属性値のデータのうち95%以上が整数の時に、
ある1件のデータだけが文字列(例えば、漢数字など)として記載されていた場合は、
このデータの形式は、間違えている可能性が高いです。
rdflintでは、このようなデータのチェックを行うことも出来ます。
但し、統計的なチェックは間違いであることが断定できないので、
「INFO」という低いレベルの問題として判定しています。
統計的に推定する場合は、
(制約の記載などの手間は不要ですが)誤判定の可能性があるので、
規定して制約によるチェックと上手く併用して頂ければと思っています。
以上のように、
rdflintでは4段階のデータチェックを行っていますが、
RDF以外のデータ作成にも、このようなチェックの考え方は応用出来ると思います。
ソフトウェア開発では、アプリケーションのロジック以外に、
データの運用ミスによる不具合が発生することも、度々あると思います。
このような考え方でデータに対しても、
CIによる自動的なテストを実施してみてはいかがでしょうか?