W3C XSD と OASIS CAM を使用して、3 つのレベルで分類するタクソノミーによるモデリング戦略を作成する

2 つのスキーマによる手法に沿って単純なモデリング戦略を検討する

問題領域を記述するための語彙を作成する場合、問題領域を 3 つのレベルで分類するタクソノミーを使用していることに気付くことがよくあります。例えば会計アプリケーションの場合、ある 1 つの元帳レコードをカテゴリー (借方または貸方) で区別し、次にそれらのカテゴリーの中でタイプとサブタイプに分類する場合があります (例えば「以前の未払いによる累積利息」の場合であれば、貸方/利息/未払費用、という 3 つに分類することができます)。XML 内のこうした構造をデータの要件に応じてモデリングする方法は何通りもあり、また多種多様なスキーマの手法を利用することで、そうしたモデリングを強制することができます。ここでは 2 つのスキーマによる方法について説明します。1 つは W3C の XSD (XML Schema Definition) による方法、もう 1 つは OASIS (Organization for the Advancement of Structured Information Standards) の CAM (Content Assembly Mechanism) による方法です。

Piers Michael Hollott, Senior Consultant, Sierra Systems

Piers Hollott はソフトウェア業界で 15 年間働いており、Java 開発、XML 技術、関数型プログラミングを専門としています。彼はいくつかのオープンソース・プロジェクトに貢献した経験があり、現在は Sierra Systems のコンサルタントをしています。



2011年 1月 18日

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

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

よく使われる頭文字語

  • ISO: International Organization for Standardization
  • W3C: World Wide Web Consortium
  • XML: Extensible Markup Language

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

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

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

表 1. 会計アプリケーション用の語彙データの例
category (カテゴリー)type (タイプ)subtype (サブタイプ)
debt (借方)interest (利息)overpay (過払い)
adjust (調整)
credit (貸方)interest (利息)overpay (過払い)
adjust (調整)
payment (支払い)eft (電子資金振替)bank (銀行)
chq (小切手)bank (銀行)
indiv (個人)
trustee (受託者)

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


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

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

リスト 1. フラットな構造の XML
<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) を詳細に見ると、語彙は正確に表現されているにもかかわらず、タクソノミーの階層間の関係が反映されていないことがわかります。

リスト 2. フラットな XML 構造に対する XSD の抜粋
<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 ではやはり categorytypesubtype という異なるメタデータの間の関係を反映することはできません。これらのメタデータの違いは XSD によって簡単に区別できるようなものではないのです。

リスト 3. 構造化された XML データ
<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)。

リスト 4. 構造化された XML データに対して生成された CAM テンプレート (抜粋)
<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 を作成しました。

リスト 5. 構造化された XML データ用に修正された 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 などの最新のスキーマによる手法を使うことで、それらの仕様そのものに加え、仕様をサポートするツールもより優れたものになっていくことを楽しみにしていてください。この記事を通じて、単純なテキスト・エディターを使って多くのことを達成できることをご理解いただけたようであれば幸いです。


ダウンロード

内容ファイル名サイズ
Example XML Filesxml-examples.zip4KB

参考文献

学ぶために

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

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

議論するために

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

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Open source
ArticleID=626475
ArticleTitle=W3C XSD と OASIS CAM を使用して、3 つのレベルで分類するタクソノミーによるモデリング戦略を作成する
publish-date=01182011