ラーメンデータをめぐるオントロ思考の大冒険

Chapter1 罠

 僕は忘れっぽい。いつどこで何を食べたのかも、もちろんすぐ忘れる。

 昼休みに食べたものを後で思い出せるように、日記的な感覚で、写真を撮りメモをしていたのが始まりだった。

 メモと写真が増えてくると、次第にこれは ラーメンデータセット ではないか、と脳が勝手に認識するようになってきた。
 それほど、ラーメンばかり食べていたのだ。

 そしていつしか、昼食メモは、ラーメンデータセットに変換されていた。

 このラーメンデータセット、1枚のエクセルシートにまとめた単純なものだった。
 僕はそれで満足だった。

 しかし、このデータを眺めているうちに、このデータを構造化し、Linked Open Data の理想形とするにはどうしたらよいか、ぼんやりと考えるようになった。
 最近読んだ本や、話した人たちの影響を受けて。

 ・・・何かの罠にはまったのかもしれない。

Chapter2 中華麺提供飲食店クラス

 僕のラーメンデータセットが持つ、主軸となる情報分野は2つ。
 1つは、ラーメン店のお店情報。もう1つは、その 店で食べたラーメンの紹介 だ。
 データセットとしての構成は、「店」が主体で、食べたラーメンは、店の持つ要素の一つ、としている。

 このデータセットを構造化するためには、主体である「ラーメン店」をどう位置づけるか、すなわち、どういった 概念クラス を設定するかを、まず考えねばなるまい。

 つけ麺や油そば など、ラーメン以外の中華麺を提供する店も多く存在する。
 また、「麺類」という枠で考えると、うどんやそば、パスタ、ビーフンなどの存在も無視できない。
 また、料理を提供する店だけでなく、麺の製造工場もあるし、スーパーやコンビニでは、様々な麺が販売されている。出前のみの店舗もあるし、お祭り屋台的な販売方法もある。

 あれこれ悩んだ結果、僕のラーメンデータにマッチするクラスは、以下の要素をすべて兼ね備える 店舗のインスタンス集合 であると結論づけた。

  • 店を構えており、店内で食事を提供する。
  • ラーメンだけでなく、つけ麺や油そば、冷やし中華などの「中華麺」のうち、いずれか1種類以上を提供する。(うどんやそばなどの、中華麺以外の麺は、中華麺に含めない。)
  • 大衆食堂やファミリーレストラン、定食店など、ラーメン専門店以外の店でも、中華麺を提供する店については、当該クラスに含むこととする。
  •  これらを要約すると 中華麺提供飲食店クラス だ。
     うーん、なんとなく違和感を感じる…。

     その違和感の正体、この時点ではよく分からなかったが、後日明らかになる。

    Chapter3 共通語彙基盤と、ラーメン人のニーズ

     ラーメンデータセット構築の際は、今一番ナウい 共通語彙基盤 を使おうと、僕は以前から考えていた。英語があまり得意でないのもあるし、ある程度ひな形ができているので、とっつきやすそう、と思ったからだ。

     共通語彙基盤の思想や取組は先進的であり、我が国の高度情報化の未来を担う礎となるものだろう。
     でもこの「共通語彙基盤」というネーミング、ちょっとイマイチと思うの僕だけかな?

     さあ、共通語彙基盤のクラス分類により、ラーメン店データの所属先の検討をはじめよう。

     クラス用語一覧 のページをひとしきり眺めたところ、どうやら ic:施設型 に所属させるのが良さげだ。お店は施設だしね。

     また、 ic:施設型 のサブクラスは、コア語彙では現在 ic:駐車場型 しかなさそうなので、コア語彙のみを用いる限りは、これ以上の細分類クラスはあり得ない。
     よって、すべてのラーメン店は、ic:施設型 クラスに所属する。めでたしめでたし。。。


     ・・・この時点で、僕は疑問を持った。
     僕らのラーメン店が属するクラスは ic:施設型 で本当によいのか、と。

     ic:施設型 では、あまりにも「ざっくり」しすぎていて、我が国9500万人(推計値)のラーメン人のニーズには応えていないように感じてならない。
     ラーメン人たちのニーズに応えるため、Chapter2で定義した 中華麺提供飲食店クラス を、ic:施設型 のサブクラスとして、きっちりと位置付ける必要があるのではなかろうか・・・

     僕は、一種の思考実験として、このことについて考えを深めることとした。

     さて、僕が買った教科書 にはこんなふうに書いてあった。
    『 クラスの下位概念をつくるときは、分類基準について一貫性を持たせなきゃだめ。別の分類軸を混ぜちゃだめ 』 と。

     僕の考えた 中華麺提供飲食店クラス は、この 一貫性 という観点で考えると、はなはだ怪しい。
     また、ラーメン店は店舗であるので「建物」であるとも言える。だからひょっとして ic:建物型 かも、という考えも頭に浮かんできた。

     頭の中がごちゃごちゃしてきたので、とりあえずラーメンで一服し、それから、頭の中を整理することとした。

     ic:施設型 は、その施設の 役割 を分類軸にしている。たぶん。
     一方、ic:建物型 は、その建物の形状、すなわち、ビルであるか、戸建てであるか、長屋であるかなどを分類軸にしている。おそらく。

     それを前提とすると、ラーメン店は、戸建ての場合も、ビルの一室にある場合もあるので、建物の形状を分類軸にするのは不適当であることが分かる。
     やはり、ラーメン店は「ラーメン等の飲食物を提供する」という 役割 で分類すべきであろう。

     要約すると、ラーメン店は ic:施設型 か、その直系下位のサブクラスに属すべきインスタンスであり、サブクラス作成の際は、役割 を分類軸とすべし、ということだ。

    Chapter4 サブクラスか、属性か

     僕はラーメン人の期待に応えるべく、ラーメン店の「約束の地」の候補地となるクラスを、ic:施設型 の下位に次々と創造していった。

     結果、我らがラーメン店は mc:飲食店型 もしくは、その直系下位クラスの中で、店を構えてもらうこととなった。

     次に、僕のデータの前提条件である「少なくとも1種類の中華麺を提供する」について検討した。
     この 中華麺の提供 という概念、これを 分類軸の一貫性 という観点で考えると、これまでの 役割 によるクラス分類とは、分類軸が少しずれているように思う。
     クラスの階層構造を、単なる タクソノミー として捉える場合は問題ないのかもしれない。しかし オントロジー としては駄目だろう。

     もし、分類軸をずらさずに mc:飲食店型 のサブクラスを設定するとしたら、下図のような分類が望ましい。

     僕のデータが、ラーメン専門店 のみを対象としたデータであれば、もう一階層下のクラスである mc:ラーメン専門店型 が最もふさわしいだろう。
     しかしながら、ここで要件としている「中華麺の提供」とは、中華麺を提供できる能力のある こと、すなわち アビリティ であり、分類軸である 役割 とは異なる。

     以上のことから、「中華麺の提供」概念は、mc:飲食店型 のサブクラスとして設定するのではなく、mc:飲食店型 の持つ 属性 として定義し、その値は ブーリアン型(True 又は False)をとる。
     このように考えると、すっきりした気分になった。

    Chapter5 メニューとは何か

     飲食店は、飲食物を提供する店のことであり、当然、飲食物の メニュー がある。
     飲食店データがその真価を発揮するのは、提供される飲食物のメニューと紐付いたときだ。

     飲食店の「店舗」としての要素は、コア語彙の ic:施設型 クラスのプロパティと、継承した上位クラスのプロパティにより、おおむね表現できる。

     しかしながら、メニューについては、どのようなオントロジーを構築し、どうやって店のデータと紐付けたらよいか・・・
     また難題にぶつかってしまった。

     そこでまず、メニューという概念が一体どのようなものであるか、突き詰めて考えることとした。

     メニューとは、店で提供される料理の一覧であり、個々の料理の集合体だ。
     また、個々の料理は、原材料である食材を加工した物だ。
     この特性と、共通語彙基盤のクラス分類軸とを考え合わせると、人の手によって作られた 製品 である料理は、ic:製品型 クラスに所属させるのが適切だろう。

     さて、前チャプターで、ラーメン店の所属先である ic:施設型 のサブクラスについて検討を行ったところだが、これはメニューについても当てはまる。
     要するに、ラーメン店の渾身の一杯を、単に ic:製品型 という枠にくくりつけるには、あまりにもざっくりしすぎていて、9500万のラーメン人のニーズに応えていない、ということだ。

     そこで、メニューについても、店の考え方に準ずることとし、ic:製品型 のサブクラスとして mc:飲食物型 を設定した。
     この mc:飲食物型 に属するインスタンスは、提供される個々の料理である。

    Chapter6 ロールとリレーション

     さて、この メニュー という概念、その実態は 個々の料理の集合体 だ。

     飲食店を主体として考えた場合、飲食店には必然的にメニューがある。このメニューという役割(ロール)を、「製品」である料理が担っている。
     その関係を図に表すと、次のようなものとなる。

     僕の教科書によると、このような関係は ロール概念 である、と述べられている。

     言い換えるとこうだ。
    『 飲食店を構成する一つの構成要素としてメニューがある。メニューは料理の集合体であり、料理は、本来的には飲食物としての性質を持つ。飲食物である料理が、飲食店においてはメニューというロールを担っている。』

     ここで視点を変えて、メニューを主体として考えてみると、全く逆の関係が成立する。

     このように考えると、店とメニューは 連動関係(リレーション) にあり、次図のような関係が成立する。

    Chapter7 二本立てか、まとめるか

     僕のラーメンデータは、1枚のエクセルシートにまとめられている。
     しかしながら、ラーメン店とラーメンは、本来、別の分類軸で分類されるものだ。
     店は施設であり、ラーメンは調理品である。
     それぞれを主語として別々のデータセットにするのが、望ましい形だろう。
     関係データベース的にとらえるなら、それぞれ別のテーブルにして、共通のキーを持たせ、リレーションさせる、ということだ。

     また、僕のデータには、各店のお勧めの品が一品だけ記されているが、店のメニューは本当はもっといっぱいある。それら複数のメニューを掲載したら、1枚のエクセルシートでは収まりきらないという、事実上の制約もある。

     ラーメン店とラーメン、それぞれを主体(主語)とし、別々のデータセットとして構築する。
     そのデータセットを、URIリンクで相互に結んだ形が、Linked Data として理想的な形なのだろう。

     僕のラーメンデータ、今は一本立てだが、お勧めメニューをもっと増やしたくなったら、上記のような二本立てのデータセットにしよう。

     体内の中性脂肪との兼ね合いもあるので、いつになるか未定であるが…

    Chapter8 コアとドメイン

     人類の食に対する執着はものすごく、世の中に飲食店の情報はあふれている。
     あまたの人間の興味の対象であるこの飲食店について、どう捉えるか。

     共通語彙基盤では、普遍的基礎概念を定義した コア語彙 だけでなく、ある分野での利用に特化した ドメイン語彙 を今後充実させる、というロードマップを描いているようだ。

     さてここで、共通語彙基盤における「飲食店」概念の位置付けについて、改めて考えてみる。

     共通語彙基盤においては、飲食店を単なる1データモデルと位置づけるのではなく、専用の ドメイン として設定し、そのドメイン語彙を整備することが、世の中に望まれているのではないか、と僕は思う。
     食べログやぐるなびなど、飲食店情報のデータベースサイトも無数に存在し、社会的ニーズが非常に高い分野だ。インスタなどのSNSへの影響も大きいだろう。
     飲食店ドメイン語彙 をIPAがきっちり整備してくれたら、もっとみんなが使いやすいものになるのになぁ。

     さて、飲食店という特定分野(ドメイン)に固有の要素は、以下のものが挙げられる。

  • メニューがある。
  • 座席がある。(立ち食いの店もあるが)
  • オーダーストップの時間がある。
  •   などなど…

     これらの要素を、ラーメンデータモデルにおいて、どう表現したらよいか。
     そこで、 コア語彙 + 独自定義語彙データモデル とした場合と、飲食店ドメインデータモデル とした場合を、それぞれ考えてみた。

    (1) コア語彙 + 独自定義語彙 データモデル

     コア語彙のクラスのみを用いて、足りないプロパティはデータの作成者が適当に定義し、そのクラスに追加する、という手軽な方法。

    (2) 飲食店ドメイン データモデル

     新たな分野ドメイン(クラス)を構築し、そのドメイン固有のクラス及びプロパティを利用する、という方法。

     僕の個人的見解では、飲食店分野はドメインとして設定するのが望ましいと考えている。
     しかしながら、今回のデータセットの作成にあたっては、手軽さと分かりやすさを優先し(9500万のラーメン人のニーズは無視して)、結局、コア語彙+独自定義語彙モデル型を採用することとした。

     飲食店ドメインは人類には早すぎたのかもしれない(嘘)

    Chapter9 オントロジカル コグニション

     長い思考の旅路の末、僕のラーメンデータは構造化され、URIをペタペタくっつけられ、参照解決を解決し、めでたく自称 五つ星 Linked Open Data となった ☆☆☆☆☆彡

     しかし本当にこの構造でよいのか、適切な語彙を使っているか、考えだしたらきりがなく、悩みと想像力は膨らむ一方だ。

     これは悪魔の罠かと思う一方、ラーメン店構造化の思考プロセスを通じて、世の中のあらゆる物事が、オントロジカルに認識されるようになり、視界が以前よりクリアになったように感じられる。

     さて、ラーメンの次は餃子でも食べようか。
     終わりなき思考とグルメの旅、そして中性脂肪との戦いは続く。

    © Masahiro Hayashi
    back