寓話
薬屋の店主は薬性、処方、禁忌を同じ薬斗の上に置いた
老舗の薬店には三つの独立した検索装置があった。一つは薬名で調べ、一つは症状で調べ、一つは処方で調べる。店主は分けて管理するのが最も明確だと言い、調剤師もそれに慣れていた。しかしある急症の処方箋があった。『麻黄湯と効能が近い処方を探し、ただし麻黄を含む薬は除外し、三歳以上の児童に適し、医療保険が使えること。』調剤師はまず処方棚を調べ、次に薬名棚で成分を調べ、さらに症状棚で禁忌を調べ、そして三つの紙の山を手作業で突き合わせた。
小弟子は対照表を一枚書いて壁に貼り、'麻黄湯→近似方→麻黄減→年齢加→医療保険加'の検索経路を並べた。二週間後、この表は例外と矢印でいっぱいになり、直接調べるより頭が混乱した。
三組の装置一式を一つの大きな総勘定の書類棚にまとめ、すべての属性を同じ行に記載しようという提案があった。統合すると確かに検索は簡単になったが、新たな問題が生じた。処方には文章で説明されたもの、数値指標で示されたもの、薬草の配合図になっているものがあり、すべてを固定の列に詰め込もうとすると、たちまち項目数が膨れ上がった。
新しく来た調剤総監は別のやり方に変えた。彼は各処方を独立したオブジェクトとして扱い、そこに同時に掛けた。類似度マッチング用の記述暗号群、正確な絞り込み用の構造化属性群、字句検索用のキーワード群、さらにカスタムの問答対と要約を掛ける空間も残した。
照会時、薬局はこれら三つの方式を同時に呼び出せる：文字記述で効能が最も近い処方を探し、構造化フィールドで禁忌と年齢を除外し、キーワードで'健脾''祛湿'のような用語を特定する。三つの信号を重み付け融合し、一度に結果を返す。
彼はさらにデータ機関上でクラス定義を行った。各クラスは属性型と索引方式をあらかじめ宣言していた。『方剤』クラスには薬材リスト、効能ベクトル、禁忌条件がある。『薬材』クラスには性味帰経ベクトル、価格、在庫がある。異なるクラス間は関連参照できる。
その後、薬局は外部データソースも接続した。医療保険目録、感染症通报、新薬承認公告。各データソースは同じデータ機関で接続され、処方オブジェクトは新しい情報を自動的に継承した。
老店主はついに認めた。処方は独立したフィールドの寄せ集めではなく、構造と意味を持ち、同時に多角的に検索できる完全な物であると。