SPARQLthon40/RDFvsCT
提供：TogoWiki
圏論（category theory）に基づくデータベースと、RDF
HC
目次 |
Background
調べた動機
- 圏論に基づくデータベース (categorical database)、あるいは、関手的データモデル (functorial data model) が一部の人たちに注目されていたようだ（参考文献）。
- 調べてみるとRDFにそっくりだが、彼らは、RDFに対する優位性を主張している（あるいは、全くRDFを知らないことも）。
- RDFと categorical database との差分は何だろう？もし差があるなら、RDFをimproveできないのだろうか？
圏論に基づくデータベース (categorical database)
圏とは、対象（object）と射（arrow）から構成されるもので、対象間を射で接続したものの集合である。
対象 A, B と 射 f の関係を f: A→B と表すことが多い。A を f の domain (source), B を f の codomain (target) と呼ぶ。
射は結合則にしたがって合成する事ができる。(h・g)・f = h・(g・f)
- これをRDFとの違いとして挙げる人もいる。SPARQL 1.1 には property path があるけど、それではダメ？
関手（かんしゅ, functor）とは、圏から圏への対応である。
- 関手があることで、スキーマが変わってもデータマイグレーションが可能だという。owl:equivalentClass 等を使ってマッピングするのに似ているが、OWLによるマッピングよりもいい点が何かあるのだろうか。
Categorical database では 圏 = データベーススキーマ とするということ。結局のところ圏は、有向グラフに恒等射と結合則を加えたようなものであり、RDF のスキーマとしても利用できるのではないか？
参考文献
- "the first author explained how a categorical database can be converted into an RDF triple store using the Grothendieck construction. The main difference between a categorical database schema (or an olog) and an RDF schema is that one cannot specify commutativity in an RDF schema."
David I. Spivak, Categorical databases Presentation (2012)
DI Spivak, Category Theory for the Sciences. MIT Press (2014)
Categorical Informatics, Inc.（2015年、Spivakら設立）
Using Category Theory to get more out of Linked Data Cambridge Semantic Web Monthly Meetup（2015年6月）
- Category theory + semantic web = hot combo
- Functor を使えば、ontology alignment やデータマイグレーションがもっとうまくできるようになるのかな。
W3C mailing-list
- category theory (2007)
- rdf and category theory (2014)
- rdf and category theory (April 2014)
- "Does anyone have some insight on what the relations between the two are?"
- Eric Prud'hommeaux "David Spivak and I looked at using category theory to back the query rewriting algorithms in SWObjects."
- "It's so odd that RDF is entirely about relations just as CT is ( except that RDF is one to many whereas CT arrows are functions). So I really look forward to understanding how these two domains fit together, and perhaps how they complement each other."
- "It turns out I overgeneralised here to soon. On page 7 of the book "Category Theory" by Steve Awodey from the Oxford Logic guides, as example 4 of different types of Categories, where the arrows are not functions."
ブログ等
関連資料
Categorical database のテスト
- FQL IDE をダウンロードして、起動
java -jar fql.jar
- FQL IDE manual の例を使ってテスト
- OrthoXMLの例でもやってみた
Todo
- SHACL仕様の最初の例を、categorical databaseスキーマで表現したら、だいぶ楽になりそう
- OWLでも書いて、比較検討できるかも
参考文献
SHACL (W3C First Public Working Draft 08 October 2015) (日本語解説)
SHCACL (W3C Editor's Draft 22 January 2016)
https://www.w3.org/2014/data-shapes/wiki/Main_Page
考察
RDFとの違いは何か
categorical database = RDF - URI - オントロジーの階層構造 + データに対する制約チェック + α
- 見方を変えると、categorical database + オントロジーの階層構造 = RDF - URI + データに対する制約チェック + α
- categorical database にオントロジーの階層構造を加えたら、ある意味improveできるか。
- α：functorとか調査できていない。パスのequationが定義でき、制約条件、例えば inverse propertyや、transitive property に相当する記述もできる。
- 両者ともグラフ型 DBMS であり非常によく似ているが、RDF の場合は DBMS と WWW 的な話がごっちゃになっているかんじがする。
URIは必要かという点について
- そもそも RDF ではなぜ URI を用いているのか。これには２つの全く異なる側面があるので、分けて考える。
- (1) データベースのエントリーIDとしてURIを利用するという側面。DBMSとしてRDFをとらえると、実はURIを使う必然性はない。URIは、ドメインの切り分けがしっかりしているので、混乱が少ないID体系として使える、ということだろう。データの中でURIを使っていると、別々の人が作成したデータでも楽に統合できる、というけれど、現実にはどれほどの恩恵があっただろうか。Tax IDのように、URIにしたせいで余計なバリエーションができてややこしくなることがある。実際には、話し合いをしてURIをすりあわせるという地道な作業が必要である。異なるデータ間でIDのマッピングをとる仕組みさえあれば、URIでなくてもデータ統合できるのでは。結局のところ、URIを用いなくても、RDFストアのようなシステムはDBMSとして動くだろう。
- (2) HTTPでさらなるデータを取得可とするためにURLを用いるという側面。RDFをハイパーテキストの一種としてとらえると、URL参照が埋め込まれることは必然であろう。このURL参照というのは、上記(1)のURIとはねらっている機能としては違うものである。実際、必ずしもエントリーIDそのものをURIとする必要はなく、エントリーIDに付随したattributeのようなものとしてURIを保持したって、URI参照としての機能は果たせるだろう。
- URIが(1) と (2) の側面を合わせ持つということ、つまり、データベースのエントリーIDでありつつ、HTTPでさらなるデータが得られるようになっているのがいいのではないか、という意見もあるだろう。でも、この性質を利用したアプリケーションがどれほどあるだろう。エントリーIDにHTTPアクセスして返ってくるデータの形式が定まっていないので、アプリケーションを開発しようにも、仕様が定まらない。HTMLが返ってくることもあるだろうし、RDFが返ってくることもあるだろう。そうして得られたデータをどのようにパースすればよいかを知る方法は定められていない。必ずJSONが返ってくるとか、データのスキーマも返ってくるとか、もっとちゃんとした決まりがないと、アプリケーションの開発は進まないだろう。
スキーマについて
- categorical database のスキーマから、RDFのスキーマ図に相当するものを作ることができる
- ただし、equationsの情報は入れられない
- RDFのスキーマ図から、categorical database のスキーマは必ずしも作れない
- 各 property の、domain と range がはっきり決まっていないといけない
- 例えば、rdfs:label とかが至る所で使われているが、これだとまずい。sequenceLabel とか organismLabel とかを個別に作るしかない
- 各 property の、domain と range がはっきり決まっていないといけない
RDF の disadvantage
スキーマの記述方法が定められていないこと
- RDFの場合、RDFストアなどのシステム側がスキーマを要求しないので、開発者がスキーマを作って"自主規制"することになる。
- SHACLのような提案もあるが、まだ一般的ではない。
- Open World Assumption に従うと、データの中に間違いが混入しても、それを排除できない。
- OWLファイルはある意味RDFのスキーマの一部を決定するものであるが、それだけではRDFのスキーマ図は作れない。つまり、データ構造の記述としては不十分な情報しか持っていない。
- どういうふうにOWLファイルを書けば、スキーマとして十分な情報となるのだろう。相当複雑なものになる。owl:Restriction, owl:onProperty などを使って記述しなければならないが、実はこの情報は、domain, range の情報とかぶることになる。矛盾した記述になることもあり得る。
- 一方の categorical database の場合は、システム側がスキーマを要求していて、データがスキーマに合うかどうかをチェックしてくれる。
RDF の advantage
RDFの強みは、オントロジーの階層を用いた推論検索ということになるだろう
- たとえば、organismLabel, geneLabel 等の上位概念として label を定義して、上位概念を使って検索できるということ
- categorical databaseだと、こういうふうに似た arrow をまとめて扱うことができない
- RDF だと、property を主語として、それについての定義をすることができる
- categorical database の場合、arrowに情報を持たせたかったら、arrowをやめて node にするしかない。
- オントロジーの階層構造をデータとして扱うなら、categorical databaseでも問題ない。実際、GOのデータとかFQLのexampleに入っていたし、taxonomyもデータとして扱えるだろう。
recursive なパスを含む構造を簡単に記述できる。たとえばtree構造のようなものの記述において。
- categorical databaseの場合、ちょっとややこしくなる
- 例えばツリー構造のデータでは、各ノードが親へのarrowを持つようにすればいいが、ルートもまた親へのarrowを持たなくてはいけない。自分自身を親とするのでいいのかな。
- propetyのdomainとrangeをはっきりしなければいけないので、場合によっては、ひとつのpropertyでは対応できなくなり、似たような複数のpropertyを作らなくてはならなくなる。
- equationsで、推移則みたいなのを定義しないと、エラーになった。
request
- スキーマ図（dot フォーマット）は、RDFコミュニティーの慣習に従った表記のほうがうれしい
- node は type または class、attribute は property、arrow は relation とした方が分かりやすい
- visualize は、GraphViz のようなレイアウトの方が見やすい
- manualを、現バージョンのIDEの動作と揃えてほしい
- saveするときとかに、ディレクトリをおぼえていてほしい
- nodeのインスタンスのIDが、どうしてそのまま、RDFのインスタンスのIDに反映されないのだろうか。
- ネームスペースの fql:// を、http://example.com/ にしてほしい
