ラーメンデータをめぐるオントロ思考の大冒険
Chapter１ 罠
僕は忘れっぽい。いつどこで何を食べたのかも、もちろんすぐ忘れる。
昼休みに食べたものを後で思い出せるように、日記的な感覚で、写真を撮りメモをしていたのが始まりだった。
メモと写真が増えてくると、次第にこれは ラーメンデータセット ではないか、と脳が勝手に認識するようになってきた。
それほど、ラーメンばかり食べていたのだ。
そしていつしか、昼食メモは、ラーメンデータセットに変換されていた。
このラーメンデータセット、１枚のエクセルシートにまとめた単純なものだった。
僕はそれで満足だった。
しかし、このデータを眺めているうちに、このデータを構造化し、Linked Open Data の理想形とするにはどうしたらよいか、ぼんやりと考えるようになった。
最近読んだ本や、話した人たちの影響を受けて。
・・・何かの罠にはまったのかもしれない。
Chapter2 中華麺提供飲食店クラス
僕のラーメンデータセットが持つ、主軸となる情報分野は２つ。
１つは、ラーメン店のお店情報。もう１つは、その 店で食べたラーメンの紹介 だ。
データセットとしての構成は、「店」が主体で、食べたラーメンは、店の持つ要素の一つ、としている。
このデータセットを構造化するためには、主体である「ラーメン店」をどう位置づけるか、すなわち、どういった 概念クラス を設定するかを、まず考えねばなるまい。
つけ麺や油そば など、ラーメン以外の中華麺を提供する店も多く存在する。
また、「麺類」という枠で考えると、うどんやそば、パスタ、ビーフンなどの存在も無視できない。
また、料理を提供する店だけでなく、麺の製造工場もあるし、スーパーやコンビニでは、様々な麺が販売されている。出前のみの店舗もあるし、お祭り屋台的な販売方法もある。
あれこれ悩んだ結果、僕のラーメンデータにマッチするクラスは、以下の要素をすべて兼ね備える 店舗のインスタンス集合 であると結論づけた。
これらを要約すると 中華麺提供飲食店クラス だ。
うーん、なんとなく違和感を感じる…。
その違和感の正体、この時点ではよく分からなかったが、後日明らかになる。
Chapter3 共通語彙基盤と、ラーメン人のニーズ
ラーメンデータセット構築の際は、今一番ナウい 共通語彙基盤 を使おうと、僕は以前から考えていた。英語があまり得意でないのもあるし、ある程度ひな形ができているので、とっつきやすそう、と思ったからだ。
共通語彙基盤の思想や取組は先進的であり、我が国の高度情報化の未来を担う礎となるものだろう。
でもこの「共通語彙基盤」というネーミング、ちょっとイマイチと思うの僕だけかな？
さあ、共通語彙基盤のクラス分類により、ラーメン店データの所属先の検討をはじめよう。
クラス用語一覧 のページをひとしきり眺めたところ、どうやら ic:施設型 に所属させるのが良さげだ。お店は施設だしね。
また、 ic:施設型 のサブクラスは、コア語彙では現在 ic:駐車場型 しかなさそうなので、コア語彙のみを用いる限りは、これ以上の細分類クラスはあり得ない。
よって、すべてのラーメン店は、ic:施設型 クラスに所属する。めでたしめでたし。。。
・・・この時点で、僕は疑問を持った。
僕らのラーメン店が属するクラスは ic:施設型 で本当によいのか、と。
ic:施設型 では、あまりにも「ざっくり」しすぎていて、我が国9500万人（推計値）のラーメン人のニーズには応えていないように感じてならない。
ラーメン人たちのニーズに応えるため、Chapter2で定義した 中華麺提供飲食店クラス を、ic:施設型 のサブクラスとして、きっちりと位置付ける必要があるのではなかろうか・・・
僕は、一種の思考実験として、このことについて考えを深めることとした。
さて、僕が買った教科書 にはこんなふうに書いてあった。
『 クラスの下位概念をつくるときは、分類基準について一貫性を持たせなきゃだめ。別の分類軸を混ぜちゃだめ 』 と。
僕の考えた 中華麺提供飲食店クラス は、この 一貫性 という観点で考えると、はなはだ怪しい。
また、ラーメン店は店舗であるので「建物」であるとも言える。だからひょっとして ic:建物型 かも、という考えも頭に浮かんできた。
頭の中がごちゃごちゃしてきたので、とりあえずラーメンで一服し、それから、頭の中を整理することとした。
ic:施設型 は、その施設の 役割 を分類軸にしている。たぶん。
一方、ic:建物型 は、その建物の形状、すなわち、ビルであるか、戸建てであるか、長屋であるかなどを分類軸にしている。おそらく。
それを前提とすると、ラーメン店は、戸建ての場合も、ビルの一室にある場合もあるので、建物の形状を分類軸にするのは不適当であることが分かる。
やはり、ラーメン店は「ラーメン等の飲食物を提供する」という 役割 で分類すべきであろう。
要約すると、ラーメン店は ic:施設型 か、その直系下位のサブクラスに属すべきインスタンスであり、サブクラス作成の際は、役割 を分類軸とすべし、ということだ。
Chapter4 サブクラスか、属性か
僕はラーメン人の期待に応えるべく、ラーメン店の「約束の地」の候補地となるクラスを、ic:施設型 の下位に次々と創造していった。
結果、我らがラーメン店は mc:飲食店型 もしくは、その直系下位クラスの中で、店を構えてもらうこととなった。
次に、僕のデータの前提条件である「少なくとも１種類の中華麺を提供する」について検討した。
この 中華麺の提供 という概念、これを 分類軸の一貫性 という観点で考えると、これまでの 役割 によるクラス分類とは、分類軸が少しずれているように思う。
クラスの階層構造を、単なる タクソノミー として捉える場合は問題ないのかもしれない。しかし オントロジー としては駄目だろう。
もし、分類軸をずらさずに mc:飲食店型 のサブクラスを設定するとしたら、下図のような分類が望ましい。
僕のデータが、ラーメン専門店 のみを対象としたデータであれば、もう一階層下のクラスである mc:ラーメン専門店型 が最もふさわしいだろう。
しかしながら、ここで要件としている「中華麺の提供」とは、中華麺を提供できる能力のある こと、すなわち アビリティ であり、分類軸である 役割 とは異なる。
以上のことから、「中華麺の提供」概念は、mc:飲食店型 のサブクラスとして設定するのではなく、mc:飲食店型 の持つ 属性 として定義し、その値は ブーリアン型（True 又は False）をとる。
このように考えると、すっきりした気分になった。
Chapter5 メニューとは何か
飲食店は、飲食物を提供する店のことであり、当然、飲食物の メニュー がある。
飲食店データがその真価を発揮するのは、提供される飲食物のメニューと紐付いたときだ。
飲食店の「店舗」としての要素は、コア語彙の ic:施設型 クラスのプロパティと、継承した上位クラスのプロパティにより、おおむね表現できる。
しかしながら、メニューについては、どのようなオントロジーを構築し、どうやって店のデータと紐付けたらよいか・・・
また難題にぶつかってしまった。
そこでまず、メニューという概念が一体どのようなものであるか、突き詰めて考えることとした。
メニューとは、店で提供される料理の一覧であり、個々の料理の集合体だ。
また、個々の料理は、原材料である食材を加工した物だ。
この特性と、共通語彙基盤のクラス分類軸とを考え合わせると、人の手によって作られた 製品 である料理は、ic:製品型 クラスに所属させるのが適切だろう。
さて、前チャプターで、ラーメン店の所属先である ic:施設型 のサブクラスについて検討を行ったところだが、これはメニューについても当てはまる。
要するに、ラーメン店の渾身の一杯を、単に ic:製品型 という枠にくくりつけるには、あまりにもざっくりしすぎていて、9500万のラーメン人のニーズに応えていない、ということだ。
そこで、メニューについても、店の考え方に準ずることとし、ic:製品型 のサブクラスとして mc:飲食物型 を設定した。
この mc:飲食物型 に属するインスタンスは、提供される個々の料理である。
Chapter6 ロールとリレーション
さて、この メニュー という概念、その実態は 個々の料理の集合体 だ。
飲食店を主体として考えた場合、飲食店には必然的にメニューがある。このメニューという役割（ロール）を、「製品」である料理が担っている。
その関係を図に表すと、次のようなものとなる。
僕の教科書によると、このような関係は ロール概念 である、と述べられている。
言い換えるとこうだ。
『 飲食店を構成する一つの構成要素としてメニューがある。メニューは料理の集合体であり、料理は、本来的には飲食物としての性質を持つ。飲食物である料理が、飲食店においてはメニューというロールを担っている。』
ここで視点を変えて、メニューを主体として考えてみると、全く逆の関係が成立する。
このように考えると、店とメニューは 連動関係（リレーション） にあり、次図のような関係が成立する。
Chapter7 二本立てか、まとめるか
僕のラーメンデータは、１枚のエクセルシートにまとめられている。
しかしながら、ラーメン店とラーメンは、本来、別の分類軸で分類されるものだ。
店は施設であり、ラーメンは調理品である。
それぞれを主語として別々のデータセットにするのが、望ましい形だろう。
関係データベース的にとらえるなら、それぞれ別のテーブルにして、共通のキーを持たせ、リレーションさせる、ということだ。
また、僕のデータには、各店のお勧めの品が一品だけ記されているが、店のメニューは本当はもっといっぱいある。それら複数のメニューを掲載したら、１枚のエクセルシートでは収まりきらないという、事実上の制約もある。
ラーメン店とラーメン、それぞれを主体（主語）とし、別々のデータセットとして構築する。
そのデータセットを、URIリンクで相互に結んだ形が、Linked Data として理想的な形なのだろう。
僕のラーメンデータ、今は一本立てだが、お勧めメニューをもっと増やしたくなったら、上記のような二本立てのデータセットにしよう。
体内の中性脂肪との兼ね合いもあるので、いつになるか未定であるが…
Chapter8 コアとドメイン
人類の食に対する執着はものすごく、世の中に飲食店の情報はあふれている。
あまたの人間の興味の対象であるこの飲食店について、どう捉えるか。
共通語彙基盤では、普遍的基礎概念を定義した コア語彙 だけでなく、ある分野での利用に特化した ドメイン語彙 を今後充実させる、というロードマップを描いているようだ。
さてここで、共通語彙基盤における「飲食店」概念の位置付けについて、改めて考えてみる。
共通語彙基盤においては、飲食店を単なる１データモデルと位置づけるのではなく、専用の ドメイン として設定し、そのドメイン語彙を整備することが、世の中に望まれているのではないか、と僕は思う。
食べログやぐるなびなど、飲食店情報のデータベースサイトも無数に存在し、社会的ニーズが非常に高い分野だ。インスタなどのＳＮＳへの影響も大きいだろう。
飲食店ドメイン語彙 をＩＰＡがきっちり整備してくれたら、もっとみんなが使いやすいものになるのになぁ。
さて、飲食店という特定分野（ドメイン）に固有の要素は、以下のものが挙げられる。
これらの要素を、ラーメンデータモデルにおいて、どう表現したらよいか。
そこで、 コア語彙 ＋ 独自定義語彙データモデル とした場合と、飲食店ドメインデータモデル とした場合を、それぞれ考えてみた。
(1) コア語彙 ＋ 独自定義語彙 データモデル
コア語彙のクラスのみを用いて、足りないプロパティはデータの作成者が適当に定義し、そのクラスに追加する、という手軽な方法。
(2) 飲食店ドメイン データモデル
新たな分野ドメイン（クラス）を構築し、そのドメイン固有のクラス及びプロパティを利用する、という方法。
僕の個人的見解では、飲食店分野はドメインとして設定するのが望ましいと考えている。
しかしながら、今回のデータセットの作成にあたっては、手軽さと分かりやすさを優先し（9500万のラーメン人のニーズは無視して）、結局、コア語彙＋独自定義語彙モデル型を採用することとした。
飲食店ドメインは人類には早すぎたのかもしれない（嘘）
Chapter9 オントロジカル コグニション
長い思考の旅路の末、僕のラーメンデータは構造化され、URIをペタペタくっつけられ、参照解決を解決し、めでたく自称 五つ星 Linked Open Data となった ☆☆☆☆☆彡
しかし本当にこの構造でよいのか、適切な語彙を使っているか、考えだしたらきりがなく、悩みと想像力は膨らむ一方だ。
これは悪魔の罠かと思う一方、ラーメン店構造化の思考プロセスを通じて、世の中のあらゆる物事が、オントロジカルに認識されるようになり、視界が以前よりクリアになったように感じられる。
さて、ラーメンの次は餃子でも食べようか。
終わりなき思考とグルメの旅、そして中性脂肪との戦いは続く。