ソフトウェア・アプリケーションにおけるタクソノミー

タクソノミーというのは、分類についての科学であり、さまざまなジャンルのものを階層構造で関連付ける方法を定義します。例えば、タクソノミーでは自然界を動物界と植物界などに分類することができ、さらに細かく種と亜種によって分類することができます。ソフトウェア・アプリケーションやオントロジーの語彙という意味でのタクソノミーというのは、アプリケーションやメッセージング・レイヤー、データセットの中にある一連のオブジェクトの区別に使われる階層構造のスキーマを指します。実際には、スーパータイプとサブタイプという 2 つのレベルで分類するタクソノミーは大まかすぎてあまり実用的ではなく、レベルが 4 つ以上あるタクソノミーでは面倒で維持するのが困難というのが私の感想です。これまでの経験から、非常に広範な種類のタスクに適しているのは 3 つのレベルで分類するタクソノミーだということがわかっています。私はこのタクソノミーの 3 つのレベルを、カテゴリー、タイプ、サブタイプと呼んでいます。

この 3 つのレベルで分類するタクソノミーの一例として、ペットショップのペットを追跡するアプリケーションであれば、カテゴリーとして犬または猫、タイプとしてジャック・ラッセル・テリア、サブタイプとして、長い毛、硬い毛、短い毛、といった分類が考えられます。3 つのレベルでデータを分類する方法には、もっと良い例が会計の世界にあり、それが単純な総勘定元帳アプリケーションです。

サンプルの会計アプリケーションの語彙

例えば、借方、貸方、支払いを追跡する会計用の総勘定元帳アプリケーションについて考えてみましょう。これらのレコードは表 1 のような語彙を使って定義することができます。

ここに挙げた単純な語彙は、このアプリケーション全体をとおして説明用に使うことにしますが、だからといって、この語彙を使って会計分野の大規模な問題領域に対応しようとしているわけではありません。この語彙を一例として使うことで、さまざまなビジネス・ドメインでの語彙の定義に役立つ手法と技術を提言しようとしているにすぎません。

上に戻る

フラットな XML 構造によってタクソノミーをモデリングする

タクソノミーによって識別された項目をモデリングするための最も容易な方法は、複数の属性を持つ 1 つの要素としてその要素をモデリングする方法です (リスト 1)。

<items>
   <item category="payment" type="chq" subtype="indiv">134.50</item>
   <item category="credit" type="interest" subtype="underpay">100.00</item>
   <item category="payment" type="eft" subtype="bank">1565.75</item>
   and so on...

この構造では階層構造のルールが何も定義されていないことに注意してください (ただし、この構造を強制および妥当性検証する際に使用されるスキーマによって定義される語彙を使用することで、データ構造の外で階層構造のルールを定義することができます)。項目の集合を表現するためにフラットな構造でも十分な場合がよくありますが、これらの項目が階層的に決定される場合には、フラットな構造では十分と言えません。

この例のようなフラットな構造はリレーショナル・テーブルの構造に似ています。既存のリレーショナル構造から抽出または変換したデータを扱う場合には、フラットな構造が実用的かもしれません。ただし、おわかりかと思いますが、こうした構造化されていない方法には欠点があります。このデータに対する XSD を作成する場合、そうした欠点に直面することになります。

この方法で属性を使用するということは、0..1 というカーディナリティーを暗黙的に強制することになります。それが適切な場合もありますが、例えば 1 つのカテゴリーやタイプに、複数のサブタイプが属しているような状況は容易に考えられます。そのような状況の好例として、先ほど説明したペットショップのアプリケーションがあります。例えばペット用のシャンプーは、複数のタイプまたはサブタイプのペットに適している可能性があります。その場合、例えば「硬い毛」と「長い毛」など、複数のサブタイプをユーザーが指定できるようにするのが妥当ですが、先ほど説明したような単純でフラットな XML 構造では、そのように表現することはできません。

XML エディターのなかには、サンプルの XML ファイルから W3C の XSD を作成することができるものもいくつもあります。コード・サンプルから XSD を生成すると、語彙生成の初期段階を確認することができます。これは有望に思えますが、スキーマの抜粋 (リスト 2) を詳細に見ると、語彙は正確に表現されているにもかかわらず、タクソノミーの階層間の関係が反映されていないことがわかります。

<xs:attribute name="category" use="required">
   <xs:simpleType>
      <xs:restriction base="xs:string">
         <xs:enumeration value="debt"/>
         <xs:enumeration value="credit"/>
         <xs:enumeration value="payment"/>
      </xs:restriction>
   </xs:simpleType>
</xs:attribute>
<xs:attribute name="type" use="required">
   <xs:simpleType>
      <xs:restriction base="xs:string">
         <xs:enumeration value="chq"/>
         <xs:enumeration value="eft"/>
         <xs:enumeration value="interest"/>
      </xs:restriction>
   </xs:simpleType>
</xs:attribute>

“category” (カテゴリー) と “type” (タイプ) によって期待どおりの値が列挙されていますが、スキーマは “debt” (借方) に該当する “type” (タイプ) と “payment” (支払い) に該当する “type” (タイプ) とを区別していません。データ入力の際に “type” (タイプ) を最初に入力するスタイルの XML エディターで XSD ファイルを扱うと便利かもしれませんが、その場合データが不正確になったり予想外のデータになったりする可能性があります。

また、XSD 内での xs:attribute ブロックの順序はまったく任意です。上で説明したタクソノミーにはカテゴリー/タイプ/サブタイプという自然な階層構造がありますが、この階層構造が XSD に反映されていません。これはフラットな XML 構造には階層構造が存在しないためです。

そこで望ましい手法として、このレコードを自然な階層構造に分割します (リスト 3)。ただし属性の使用をやめる必要はありません。code 属性を使用すると、各要素を非常に簡単に識別することができます。おわかりのことと思いますが、残念なことに XSD ではやはり category、type、subtype という異なるメタデータの間の関係を反映することはできません。これらのメタデータの違いは XSD によって簡単に区別できるようなものではないのです。

<sample xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:noNamespaceSchemaLocation="sample_structured.xsd">
   <items>
      <item>
         <category code="payment">
            <type code="eft">
               <subtype code="bank"/>
            </type>
         </category>
         <value>100</value>
      </item>
      <item>
         <category code="debt">
            <type code="interest">
               <subtype code="overpay"/>
            </type>
         </category>
      <value>23</value>
   </item>
   and so on...

xsi:noNamespaceSchemaLocation で参照される XSD ファイルを見ると、XSD の構造が少し変更されているけれども、XSD の語彙部分を構成する制約と列挙は変更されていないことがわかります。XSD のような文法によるスキーマの現実として、データに適用されるビジネス・ルールを容易にモデリングすることができず、XSD を使用する限り、それはほとんどどうにもなりません (少なくとも W3C XSD のバージョン 1.0 の仕様ではどうにもなりません。こうした制約は来たるバージョン 1.1 の仕様で対応されつつありますが、バージョン 1.1 の仕様はまだ完成していません)。幸いなことに、利用可能な選択肢は XSD のみではありません。

上に戻る

OASIS CAM を使ってデータ・モデルを拡張する

OASIS CAM はテンプレート・ベースのスキーマによる方法であり、ISO Schematron に使用されているのと同様の XPath のアサーションによる方法を使用して XSD を拡張することによって機能します。OASIS CAM テンプレートでは XPath を使用して XML データ内の具体的なノードとノードのパターンを特定するため、OASIS CAM は XSD よりもはるかに表現力が豊かです。また CAM テンプレートを使用すると、語彙やタクソノミーなどのドメイン特有の事項とビジネス・ルールとをテンプレート内の独自のセクションに分離できるという追加のメリットもあります。CAM は OASIS 勧告の採用を促進するために提供された一部のオープンソース・ツールでサポートされていますが、私はこれらのテンプレートをテキスト・エディターで直接変更する方法も実用的であることに気付きました。皆さんには、既に用意されているツールとテキスト・ベースの方法の両方を使用することをお勧めします。テンプレートが用意できると、そのテンプレートを使用してスキーマをベースにサンプルの XML ファイルを作成することができ、また既存の XML データの妥当性検証をすることもできます。

上に戻る

CAMProcessor を使って CAM テンプレートを生成する

CAMProcessor ツール (オープンソースの jCAM プロジェクトを Eclipse 風に実装したもの) を使用すると、ingestion (取り込み) と呼ばれるプロセスによって XSD ファイルから OASIS CAM テンプレートを生成することができます。このオプションを利用するためには、CAMProcessor の「File (ファイル)」メニューから「New (新規)」 > 「New Template from XSD (XSD から新規テンプレート作成)」の順に選択します。この記事のサンプル・ファイルの中にある sample_structured.xsd ファイルから新しいテンプレートを生成すると、sample_structured_generated.cam というようなファイルがあることがわかります。このテンプレートの BusinessUseContext セクションにあるルールに注目してください (リスト 4)。

<as:BusinessUseContext>
   <as:Rules>
      <as:default>
         <as:context>
            <as:constraint 
               action="makeRepeatable(//items/item)" />
            <as:constraint 
               action="restrictValues(//item/category/@code,'debt'|'payment')" />
            <as:constraint 
               action="restrictValues(//category/type/@code,'chq'|'eft'|'interest')" />
            <as:constraint 
               action="restrictValues(//type/subtype/@code,'bank'|'indiv'|'overpay')" />
            <as:constraint 
               action="datatype(//item/value,byte)" />
         </as:context>
      </as:default>
   </as:Rules>
</as:BusinessUseContext>

CAM テンプレートの BusinessUseContext セクションには、テンプレートに表現されたビジネス・ルールがすべて含まれています。つまり BusinessUseContext セクションでは、テンプレートをベースにした XML ファイル、またはテンプレートによって妥当性検証された XML ファイルで使用される語彙を見つけることができます。リスト 4 からわかるように、テンプレート内の語彙は別セクションに分けられています。また、category ノード、type ノード、subtype ノードとの対応に使用される XPath パターンには、3 つのレベルで分類するタクソノミーの階層構造がより適切に反映されるようになりました。しかしメタデータ同士の関係には相変わらず対応していません。そしてまさにこの部分で、テンプレート内で使用される XPath をさらに活用する必要があります。

3 つのレベルで分類するタクソノミーを表現するように CAM テンプレートを修正する

リスト 5 は、この記事のサンプル・ファイルの中にある sample_structured_modified.cam の抜粋です。私は生成された CAM テンプレートをテキスト・エディターで編集することにより、手作業でこの sample_structured_modified.cam を作成しました。

<as:BusinessUseContext>
   <as:Rules>
      <as:default>
         <as:context>
            <as:constraint action="makeRepeatable(//items/item)" />
            <as:constraint action="restrictValues(
               //item/category/@code,'payment'|'debt'|'credit')" />
            <as:constraint action="restrictValues(
               //item/category[@code="payment"]/type/@code,'eft'|'chq')" />
            <as:constraint action="restrictValues(
               //item/category[@code="debt"]/type/@code,'interest')" />
            <as:constraint action="restrictValues(
               //item/category[@code="credit"]/type/@code,'interest')" />
            <as:constraint action="restrictValues(
               //item//type[@code='eft']/subtype/@code,'bank')" />
            <as:constraint action="restrictValues(
               //item//type[@code='chq']/subtype/@code,'bank'|'indiv'|'trustee')" />
            <as:constraint action="restrictValues(
               //item//type[@code='interest']/subtype/@code,'overpay'|'adjust')" />
            <as:constraint action="datatype(//item/value,byte)" />
         </as:context>
      </as:default>
   </as:Rules>
</as:BusinessUseContext>

BusinessUseContext セクション内にある各ノードの制約を特定するための XPath が変更され、表 1 の関係が表現されていることに注意してください。XPath は柔軟なパターン・マッチングによって要素の突き合わせを行えるため、この変更は非常に単純でした。パターン・マッチングによって一致した各要素に対し、code 属性の値として考えられる一連の値が記されています。この一連の値はリスト 2 に示した一連の値と大幅に異なるものではありません (リスト 2 は第一歩として XML データをフラット・ファイルとして表現した XSD です)。しかし XPath の表現が追加されたことにより、今度は 3 つのレベルで分類するタクソノミーによる多様なコード値の間の関係を完全にモデリングすることが可能になっています。

上に戻る

まとめ

DTD (Document Type Definition) や XSD など、文法ベースのスキーマは、表現力の点で OASIS CAM や ISO Schematron などのスキーマには勝てません。これは OASIS CAM や ISO Schematron が XPath によってもたらされる表現力を活用しているためです。XML データセットを定義するために OASIS CAM や ISO Schematron によるスキーマで使用される XPath を少し変更することで、カテゴリー、タイプ、サブタイプという 3 つのレベルで分類するタクソノミーなどの一般化されたビジネス・モデルを活用することができます。それは XML によって記述されるデータでペットショップの顧客を追跡する場合であっても、一般的な総勘定元帳アプリケーションで会計記録を追跡する場合であっても同じです。より表現力の優れたスキーマを使用することで、よりデータが正確になり、また相互運用性も高まります。OASIS CAM などの最新のスキーマによる手法を使うことで、それらの仕様そのものに加え、仕様をサポートするツールもより優れたものになっていくことを楽しみにしていてください。この記事を通じて、単純なテキスト・エディターを使って多くのことを達成できることをご理解いただけたようであれば幸いです。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

学ぶために

• 「Meet CAM: A new XML validation technology」(Brian M. Carey 著、developerWorks、2009年9月) は、セマンティックで構造的な妥当性検証を次のレベルに高める方法として OASIS CAM を実践的に紹介し、また OASIS CAM の方法が他のスキーマとどのように異なるかを解説しています。
  
  
• 「OASIS CAM (CAMV) を使った XML 妥当性検証フレームワーク」(Puneet Kathuria、David Webber、Martin Roberts の共著、developerWorks、2010年5月) は、宣言型プログラミングの手法に基づいて XML データの妥当性検証ルールを作成する方法を説明しています。実践的な例として、CAM テンプレートを使って自動車業界のサプライチェーンのメッセージングをサポートする方法について説明しています。
  
  
• 「Taking XML Validation to the Next Level」(Michael Sorens 著, devx、2009年5月) をよく読んでください。この優れた連載記事では OASIS CAM の多くの機能を紹介しています。
  
  
• developerWorks の XML ゾーンには、XML 分野でのスキルを磨くためのリソースが豊富に用意されています。
  
  
• developerWorks のコミュニティーで developerWorks のエクスペリエンスをパーソナライズしてください。
  
  
• XML および関連技術において IBM 認定技術者になる方法については、IBM XML certification を参照してください。
  
  
• developerWorks の XML ゾーンを XML の技術ライブラリーとして利用してください。広範な話題を網羅した技術記事やヒント、チュートリアル、技術標準、IBM Redbooks などが用意されています。また、他にも XML に関するヒント記事があります。
  
  
• developerWorks の Technical events and webcasts で最新情報を入手してください。
  
  
• developerWorks on Twitter で今すぐ developerWorks のツイートをフォローしてください。
  
  
• developerWorks podcasts ではソフトウェア開発者のための興味深いインタビューや議論を聞くことができます。
  
  
• developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。
  
  

製品や技術を入手するために

• オープンソースの jCAM プロジェクトをダウンロードしてください。このプロジェクトには CAMProcessor アプリケーションが含まれています。
  
  
• IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
  
  

議論するために

• XML zone discussion forums に参加してください。これらのフォーラムでは XML を中心に議論が行われています。
  
  
• developerWorks コミュニティーで開発者向けのブログ、フォーラム、グループ、ウィキなどを利用しながら、他の developerWorks ユーザーとやり取りしてください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ソフトウェア・アプリケーションにおけるタクソノミー
• サンプルの会計アプリケーションの語彙
• フラットな XML 構造によってタクソノミーをモデリングする
• OASIS CAM を使ってデータ・モデルを拡張する
• CAMProcessor を使って CAM テンプレートを生成する
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント