実装設計でタクソノミーを使ってみる

実装設計でHTML5の仕様をDBへロードした後気が付いたのですが、それまで
言語の仕様やAPIのインターフェースは、単なるローカルオントロジー（OTG）だと
考えていました。しかし考えが間違っていて、タクソノミー（TXM)として考えた方が
適していると考えを改めました。

勝手に根拠みたいなことを考えてみました。
＊言語やSWの規格等はそもそもHWとやり取りする為にある。理解してもらう相手
が人間ではなくて、機械であること。
＊ほとんど日常生活では関係がないような、パラメータである場合がほとんどで
あること。
＊従ってプロトコル定義そのものであること。

こんな対象のデータをOTGでは扱いにくいので、TXMで扱うべきだと考えました。

このように考えると、TXMなので意味を追及しないで言語の習慣になれれば、
プログラム言語も習得し易くなりました。
例えば、Prolog＋Erlang習得をすれば関数型言語の仕様が半分程度理解ができる。
Haskellのモナドをフレームワークと捉える（IIJの山本和彦氏）
以上の、ことが素直に理解できるようになった気がしています。

話が脱線しましたが、HTML５の言語仕様のような場合は、メタデータを多次元で
構造化して、DBのテーブルを定義すれば、比較的簡単にデータをDBへロード
することができます。

では言語仕様をDBへ入れ込んで何が嬉しいのかピント来ないかもしれませんが、
言語の構造がどうなっていて、構造を正規化して持つことが重要だと考えています。
言語には文法をBNFで定義することが一般的ですが、パーサを掛ける時はBNF
からパーサを作成して解析すれば、シンタックスまでは解析できます。
しかし、セマンテックな部分までは殆ど理解できません。
プログラムコードをセマンティクな部分まで解析が必要な場合は
APIやフレームワークの部分をTXMを使い構造化する必要があります。

XBRLはタクソノミーを利用している技術ですが、ここで指向していることは
データフォーマットにあたるところのタクソノミーではなくて、プログラム
側でのコンテキストに対する、タクソノミーの適用を指しています。
システム開発手法では、情報資源管理（IBM,1982年)を再度TXMで取り組むことを
検討してみてもいい時期に来ていると考えています。

将来プログラム言語のベンダーがAPIの情報をXML化して提供してくれる
ことを切に願う今日この頃です。

業務設計でオントロジーを使ってみる

システム開発を想定して、ツールとしてOTG(オントロジー)やTXM(タクソノミー)を利用する作業を検討してみると、
上流設計では、業務分析をする場合、ユーザから帳票・伝票、DB、画面等の資料を
使い業務の用語を定義する目的で、データディクショナリ（DD)を作成します。
この業務をローカルOTGを構築する見たいに作業すると、DDの用語を分類する場合
メタの概念をツールとして利用するのが便利です。
メタデータをまず用意します。「プロセス、サブプロセス、アクティビティ、ロール」
２つのメタデータ同士で階層化すると
「プロセス<-サブプロセス」
「サブプロセス<-アクティビティ」
「ロール<-アクティビティ」
次に「帳票、伝票、テーブル、画面」をメタデータとすると、
「アクティビティ<-(IO)帳票」
「アクティビティ<-(IO)伝票」
「アクティビティ<-(IO)テーブル」
「アクティビティ<-(IO)画面」
（この場合はアクティビティにはロールも条件として入る場合は省略して。）

この作業はMS-Excel等の表で行えば簡単に作成できます。
例えば、プロセスであれば、名称：販売管理、説明：その業務概要説明になります。
テンプレート化したければ、IDを機械的に追加すればいいでしょう。
ここまでは、誰でも実施している作業で別に業務フローを自動で描いてくれる
訳でもないので、無駄なことかもしれません。
そこでOTS的に考えれば、IDを振ることにより、業務で使われている用語を正確に
分類することが可能になります。
例えば、帳票で使われている用語とDBで使われている用語が「多分同じものを指して
いるのだろうが？」違う場合。
その逆で少し意味が違う意味を指しているはずなのに、同じ用語が使われている
場合です。
IDを振ることにより、名称に左右されない正確な設計ができるようになります。
又この整理された情報はそのまま業務のテンプレートになるので、保守の作業で
正確に業務を把握したい場合役に立ちます。同じ業態には再利用も可能になります。
以上の内容については、詳細についてこの後のブログで説明をしていますので、もっと
掘り下げておきたい方は、そちらをお読みください。

オントロジーとタクソノミーのツール

今私たちは、情報洪水の中にいます、泳ぎの下手な人もいますし、得意の人もいると思います。 このような状況で、救命ボートはどこにあるのでしょうか、このブログが何かのヒントとなることを 願って、ブログを書いていきます。

オントロジーとタクソノミーをツールにして、何か有効な情報を提供していければと考えています。

まずは、ここでのオントロジーとタクソノミーの使い分け方ですが、Wikiを参考にしてみると、

オントロジー
「オントロジー」『フリー百科事典　ウィキペディア日本語版』（http://ja.wikipedia.org/）。2013年5月30日15時（日本時間）現在での最新版を取得。
オントロジー：オントロジー（英: ontology）は、哲学用語で存在論のこと。 ものの存在自身に関する探究、あるいはシステムや理論の背後にある存在に関する仮定という意味である。 これから派生して情報科学等でも用いられる。

タクソノミー
「分類学」『フリー百科事典　ウィキペディア日本語版』（http://ja.wikipedia.org/）。2013年5月30日15時（日本時間）現在での最新版を取得。
分類学（ぶんるいがく、英語: taxonomy）とは生物を分類することを目的とした生物学の一分野。 生物を種々の特徴によって分類し、体系的にまとめ、生物多様性を理解する。

本ブログでのツールとしての定義

オントロジーのツール
業務用語等の言葉の意味を定義し、これを関係づけ構造化すること、またはフレーム

タクソノミーのツール
業務用語やインスタンス等を機械的に分類し、これを関係づけ階層化すること、またはフレーム すなわち「意味構造化」か「単純階層化」の主な違いがある。

以下、
オントロジーはOTG
タクソノミーはTXM
で記述します。

OTGとTXMの違いは私達の日常生活や仕事をするうえで関係することがあるのでしょうか？
数学者であれば、全く違うので「何をいまさら」という話なのかもしれません。
1冊の専門書で例えるのであれば、先頭の目次がOTGで、最後の索引がTXMでしょうか。
両者の違いは、目次は著者の意志や書籍の暗黙の決まりで、人が決めると思います。
索引は、本の内容が完成してから書のページが決まってから初めてコンピュータ処理して 機械的に作成されます。
もう一つの例え方として漢字の分類方法を考えると、文字の画数で分類することをTXMで、文字の意味を分類することがOTGで行っています。
こうしてみるとどちらも本の内容をガイドラインとして説明しているのに明確な違いがあることが解ります。

ではシステム開発の現場ではどうなっているのでしょうか？

業務担当者であれば、オントロジーのことは単なる辞書的な意味を構造化したものとして 意識することは容易に想像できることかもしれません。反対に、 「コミュニケーションはシステム屋さんと、いつも普通の言葉で、できているので問題ないよ」 オントロジーなんで関係がないと思うかもしれません。
又、SEの話は時々宇宙語を話していて話がいつも通じないと感じているかもしれません。

システム担当者側はどう考えているのでしょうか、業務部門が明確な要件や仕様を出してくれないんで 困っています。「これでは来月のシステムリプレースに間に合わないよ」てことになっていませんでしょうか。

システム開発に考え方を適用すると、大体ユーザの業務はOTGで定義や設計ができます。
実装技術では主にTXMで体系つけられた技術を理解して使いこなす必要があると思います。
ユーザの業務はローカルなOTGで、商法、税法、その他法の制約の元で、暗黙の合意で
社内業務OTGが存在していて、この業務を業務分析して、SEはOTGを無意識的に理解し、
実業務を設計していると考えています。これを要件定義（RFP）とします。

実装の方に目をやると、HW、SWの制約や非機能要件や、保守運用要件などを考慮して
設計を進めるわけですが、HW、SWの知識は殆どがTXMに分類される知識ではないのでしょうか？
悲しいかな、システム毎にHW：サーバ、クライアントPCやネットーワーク機器も異なりますし、
SW:OS、DB、開発言語やフレームワークやそのバージョンまでもどんどん変化していきます。

システム開発の分野ではこのTXMが２，３年でどんどん変化していることが現実です。
１０年、２０年経験していくと、もっと上位から把握する手法が必要であると考えています。
このヒントとしてOTGとTXMのツールを意識的に適用することは非常に重要だと考えています。

---

このブログの主旨を簡単に説明します。私はシステム開発をしているSEです。 「思考のツールとしてオントロジーとタクソノミーを使う」 このツールを使うことで、より整理したシステム開発が行えて、効率の良い開発ができると考えました。
今まで経験を通して知り得たことを誰かへ伝えるために、又考えをまとめることや意見交換の目的でブログを書いていきます。