N次元木については2006年6月に本サイトにて最初のコラムを掲載しましたが，その後発行された書籍の付録に，リライトしたコラムを載せましたので，その中から抜粋して，木のイメージを紹介します。

2006年11月2日発行
「Visual Studio 2005 ASP.NET 2.0 Webアプリケーション開発 Programming Technique」
付録コラム「Web2.x以降のWeb社会を読み解くためのヒント」より抜粋

　「仕様上のこの問題さえなければプログラミングがやりやすいのに、もっとこんな処理もできるのに」、と思ったことが，エンジニアなら一度や二度はあるはずだ。そのような，仕様に対しての疑問を持った時、仕様自体について思い巡らせてみる姿勢も、時には必要ではないだろうか。
　今後，XMLを超える新しいデータ形式を生み出し、言語仕様を策定し、パーサを開発した企業が、最終的には、生き残るだろう。

　XMLは、階層構造を持つ情報を表現でき、さらに不定形の構造のデータも吸収できる、シンプルな仕様である。木構造であり，絞り込み検索のデータを表現するには最適である。しかし、ひとつ，課題がある。絞り込み可能であるというメリットは，逆に，デメリットでもあるのだ。XMLでは（というよりも，木構造では），視点の異なる構造の複数の木を，1本の木にすることができないのである。

　ひとつの例をあげて説明しよう。
　リスト1は、ある異業種交流グループに参加している人の個人情報を、会社に視点を置いて記述したXML文書である。このリスト1に、任意の個人の地域での役割のデータを追加すると、リスト2のようになる。だが，これでは会社の情報と地域の情報がランダムに並ぶことになってしまう。リスト3のように属性として追加しても，不自然である。この社員は勤務先の社内で、地域の役割を果たしているわけではないのだから。
　リスト1は、タグの意味が明確なXMLである。だが、リスト2やリスト3のように、異なる視点から見たデータを部分木として連結すると、タグ付けの意味が曖昧になってしまう。

【リスト1】異業種交流グループの参加者情報を、会社に視点を置いて記述したXML文書

【リスト2】リスト1に、参加者の地域における役割の情報を，要素として追加した例

【リスト3】リスト2の地域における役割の情報を、属性として追加した例

　今度は逆に、リスト4のような、個人に視点を置いて記述したXML文書を作成してみる。これは，任意の参加者を表すプロパティを属性として追加したものである。この文書に、地域での役割の情報を追加すると，リスト5のようになる。リスト5は、任意の参加者の所属と地域での役割を的確に表している。
　しかしながら、この参加者が会社の特定の部署の、特定のグループの従業員であるというヒエラルキーの意味は薄れている。このような構造でも，タグ付けの意味は曖昧になる。

　これがRDBであれば、会社から見た個人情報と、自治会から見た個人情報と、個人から見た自分の所属先情報といった、異なる視点からとらえられるデータは、複数のテーブルに分けて管理すればよいかもしれない。もしくは、個人に対して主キーを振り、XMLでいうところのリスト5のように、所属先情報も地域における役割の情報も、全て個人の属性として、1個のテーブルに押し込んでもいい。

【リスト4】異業種交流グループの参加者情報を、個人に視点を置いて記述したXML文書

【リスト5】リスト4に、参加者の地域における役割の情報を追加した例

　XML文書の利用目的から見れば、参加企業単位での絞り込み検索処理を目的とするのであれば、リスト1のように、「会社に属する、部署に属する、グループに属する任意の社員」という階層構造が望ましい。
　逆に、特定の人物の企業内での所属情報を得ることが目的であれば、リスト4のように「会社名、部署名、グループ名等は、任意の社員のプロパティ」という形が望ましい。
　開発の現場では、処理目的に応じたXMLを、使い分けたり、併用することが多い。複数の利用目的がある場合，オリジナルのXML文書から、別のXML文書に変換したうえで処理する方法がとられるが，別のXML文書をディスクに保存せず，メモリに展開するとしても，結局は1本の木を処理するのではなく、複数の木を処理していることに変わりはない。

　XMLの木モデルは非常に柔軟であり，我々の社会システム、人間の行動の大半を表現することができる。たとえば，人の行動予定表は，XMLで十分表現できることができる。

　リスト6は，ある社員の行動を表現したXML文書である。
懇親会と忘年会の開催日が同じであるので，どちらかが時間的に先に開催されるか，あるいはこの社員が中座して別会場へと駆けつけることになるのであろうと推測される。この文書を見て，忘年会場と懇親会場に，同一人物がいるという事態は，誰も，（データをチェックするようプログラミングされた計算機も），想像すまい。複数の＜予定＞要素ノードには，プライオリティがある。

【リスト6】ある社員の行動をXMLの構造で表現した例

　XMLでは，各ノードが同時に親子兄弟関係であって且つフラットな関係であるという構造は記述しえない。
　もし、このリスト6から、親子兄弟、祖先子孫という「相対的な関係の概念」を取り払ってしまうと、SFまがいのデータが許されることになってしまう。1個のXML文書の中に、同じ階層に同じ要素が同じプライオリティで存在することはできないのである。
　このことは，XMLの問題でも制約でもなく，データベースの常識であり、むしろ必要な条件ですらある。識別子の付けようのないノードが存在するなど、論外である。ノードは必ず一意なものであり，ユニークIDは必ず一意でなければならず、いずれも重複することはない。

　そもそも構造の異なる木を1本にまとめようとするのではなく、複数のスキーマに基づく複数の文書ファイルを1つのフォルダに格納したり，必要なデータを持つノードだけを抽出して1本の木にまとめたり，XMLデータベースに格納して表形式データと共存させたり，そのような前処理の上で，必要データを処理すればよいというのが，現時点での大方のXML屋の考えかたであろう。実際，XMLアプリケーション開発にたずさわるプログラマたちは，そのようにして，木構造データを処理している。
　もっとも，そういった前処理が必要であること自体が、とりもなおさず、現行の木構造のデータ形式に、「工夫しなければならない」問題があることを暗示しているのだが。

　視点の異なる複数の木は，1本の木にはならない。前掲のリスト1のような階層化構造と、リスト4のようなプロパティ中心の構造を、1本の木とすることはできない。だが，視点の異なるXML文書を，レイヤーのように重ねて処理（縦断検索）することならできる。
　1文書中に、同じプライオリティのノードを複数記述することはできない。だが，親ノードにpriority属性を追加して、同じ属性値を使うことにより，同じプライオリティであることを表現することはできる。
　Visual Studion 2005でXmlDataSourceに指定できるXML文書のように（このコラムは，Visual Studion 2005発表直後に執筆されたものである），入れ子の要素から成る構造ではなく、データを属性値とする，連結の容易な単純な構造としておく方法もある。データをプロパティ値として扱うのは，現実的でプログラミングも容易な設計方法である。

　いずれ、我々自身や、社会システム、人間の行動の、大部分を表現でき、どのような変更にも柔軟に対応できる、唯一のデータ形式がもとめられるようになり，この「工夫しなければならない」問題は解決されるだろう。
　そのような新しいデータ形式が，どこかで産声をあげるとすれば，そのキーワードは「次元」である。
　XMLであってもRDBであっても、従来のデータ形式では、同じ次元でデータを扱う。そこに「次元」という概念による区別を持ち込むことによって、データを特定するための「ユニークID」の重複を許可するのである。

　次世代のデータ形式のイメージを考えるために、ヒントになるかもしれないイメージを考えてみよう。
但し、これはあくまでイメージにすぎず，それ以上の何ものも示唆するものではない。

　まず、1本の木の構造を，ルートノードと要素のみのモデルで表現してみる。
　図1のように，原点にルートノードがあり、要素ノードが別の軸の上に存在するようなイメージを想像してほしい。
　そして、要素ノードの箇所で、任意の軸をツリーの枝に見立てて手折り、図2のように多面体上にマッピングする。
　この段階では、ルートノードは要素ノードに対してプライオリティを持っている。

【図1】ルートノードと要素のみのモデル

【図2】
この図では，ルートノードは要素ノードに対してプライオリティを保っている。

　さらに、要素ノードは、別のツリーのルートノードとなることができ、連結方法如何では、深い階層構造の表現が可能になる。ルートノードは随時移動し，任意の要素ノードが、ルートノードになりうる。この時、ルートノードはルート要素ノードとなる（現行の仕様では、ルートノードとルート要素ノードは異なる）。
　つまり，基点となるルートノードと、単独でも存在しうる要素ノードのみから成り、それらが処理目的によって滑って移動したり結合する、カレントノードが縦横無尽に移動するようなイメージである（図3）。この図では，「A」のData3と「C」のDeta1が重なってしまうように見えるが，それは我々がイメージしやすい3次元の多角形にマッピングした形で表現しているからである。そのため、それ以上の"次元"という概念が必要になる。
　ノードの特定には，階層や順序よりも、視点と処理対象との「相対的な関係」が重要である。各々のノードは、一切の包含関係を持たないが、相互に木としての関係がある。だが，それでも，これは木である。

【図3】視点と処理対象との「相対的な関係」から成るノードのイメージ。
要素ノードは、別のツリーのルートノード且つルート要素ノードにもなるモデル

　ひどく漠然とした話だと感じられるなら，複雑な前提条件設定と、流動的な検索キー指定の必要な，検索アプリケーション開発について考えてみればいい。質問の目的が明らかに異なる多項目のアンケート結果やグラフを表現する場合，前提条件となる項目が多岐にわたれば、その結果の表現には、多くの軸が必要となる。それらの軸にあるノードの処理についてイメージしてみてはどうだろうか。

　このような問題の解決は，XMLアプリケーションのプログラミングレベルで行うものではなく，過渡期にはパーサ，後には，ハードウェアのレベルで行われるようになる。
　過渡期には，パーサが，文頭から末尾へではなく，多角形の内側，つまり全てのノードに対して同じ距離から走査を行うようになるだろう。その時点では，ハードウェアは現行のままであるから，定義ファイルが必要となり，その中には，dislocation、bond、hybridization、glide、splitting、プロパティとして、mobility、shear、tensileといった言葉が見受けられるようになるかもしれない。サイエンスとテクノロジは一体化する方向へと進んでいく。

　ところが、我々は同じ人間であっても，それぞれ，専門分野の違いなどから，「次元」という，同じ音と表記の言葉に対して異なるイメージを持っている。ハードウェアの開発者と，パーサの開発者と，XMLアプリケーションのプログラマ（もはやXMLとは呼べないであろうが）と，ユーザが、新しいデータ形式に対して，同じ概念をイメージして理解できなければ、活用されるアプリケーションは開発しえないにもかかわらず，である。
　何十年か先に、画期的進化を遂げたハードウェアが実用化され，価格も安定し，それに伴って新しい仕様が策定され、パーサが開発されても、アプリケーション開発者やエンド・ユーザーのイメージ力が追いつかなければ、新しいデータ形式は、絵に描いた餅に終わってしまう。

　ここでいう「イメージ力」とは、デザインやイラストのようなヴィジュアルの仕事に携わる人たちに共通する、視角の延長線上にある、色や形を想像しながら考える方法（ヴィジュアル・シンキング）のことではない。数学者や物理学者や哲学者に訪れる「ヴィジョン」のようなものである。つまり、開発者にも，ユーザーにも、数学者や物理学者や哲学者が使いこなす「ヴィジョン」と同じ感覚の求められる時代が来る。

　脳科学の発展とともに、このような新しいデータ形式と社会システムを関連させた考え方に、取り組む人たちが増えてくるだろう。なぜなら、それは「存在とは何か」というテーマにすら関連してくる問題だからである。

　このように考えてみればいい。読者の皆さんは、それぞれ名前を持つ、一人の存在（一意のID）である。そうはいっても、その内面には、いろいろな立場、いろいろな属性、言い換えればいろいろなパーソナリティがあるはずだ。しかし、存在から捉えても、そのパーソナリティから捉えても、その人はその人、あなたはあなた、である。

　データ形式について考えることは、我々に、「私」とは何かという問題を突きつける。