特開2024-86706効率的なグラフデータベースストレージのためのデータ構造
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024086706
(43)【公開日】2024-06-27
(54)【発明の名称】効率的なグラフデータベースストレージのためのデータ構造
(51)【国際特許分類】
G06F 16/22 20190101AFI20240620BHJP
【ＦＩ】
G06F16/22
【審査請求】未請求
【請求項の数】14
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023212807
(22)【出願日】2023-12-18
(31)【優先権主張番号】22306928.7
(32)【優先日】2022-12-16
(33)【優先権主張国・地域又は機関】EP
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】500102435
【氏名又は名称】ダッソー システムズ
【氏名又は名称原語表記】ＤＡＳＳＡＵＬＴ ＳＹＳＴＥＭＥＳ
(74)【代理人】
【識別番号】110001243
【氏名又は名称】弁理士法人谷・阿部特許事務所
(72)【発明者】
【氏名】エリック ヴァレ グレニッソン
(72)【発明者】
【氏名】ジャン－フィリップ サウト ディザーン
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175KA07
5B175KA12
(57)【要約】
【課題】ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するための改良された方法を提供する。
【解決手段】本開示は、特に、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するコンピュータ実装方法に関する。この方法は、１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含むグラフデータベースのタプルのグループを表す、ステップを含む。この方法は、１つまたは複数の隣接行列の各々について、配列を含むデータ構造を格納するステップをさらに含む。配列は、各々が隣接行列の小区分を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む。
【選択図】図１
【解決手段】本開示は、特に、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するコンピュータ実装方法に関する。この方法は、１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含むグラフデータベースのタプルのグループを表す、ステップを含む。この方法は、１つまたは複数の隣接行列の各々について、配列を含むデータ構造を格納するステップをさらに含む。配列は、各々が隣接行列の小区分を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む。
【選択図】図１
【特許請求の範囲】
【請求項1】
ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するコンピュータ実装方法であって、前記方法は、
１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含む前記グラフデータベースのタプルのグループを表す、ステップと、
前記１つまたは複数の隣接行列の各々について、配列（ＮＶ）を含むデータ構造を格納するステップであって、前記配列は、
各々が前記隣接行列の小区分を指す１つもしくは複数のインデックス、および／または
各々が前記隣接行列のそれぞれの小区分の前記ＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む、ステップと
を含む方法。
１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含む前記グラフデータベースのタプルのグループを表す、ステップと、
前記１つまたは複数の隣接行列の各々について、配列（ＮＶ）を含むデータ構造を格納するステップであって、前記配列は、
各々が前記隣接行列の小区分を指す１つもしくは複数のインデックス、および／または
各々が前記隣接行列のそれぞれの小区分の前記ＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む、ステップと
を含む方法。
【請求項2】
前記配列の前記１つまたは複数の要素の各々は、
１つまたは複数の座標ペアのセットを含み、各ペアは、前記隣接行列におけるそれぞれの座標を表す、請求項１に記載の方法。
１つまたは複数の座標ペアのセットを含み、各ペアは、前記隣接行列におけるそれぞれの座標を表す、請求項１に記載の方法。
【請求項3】
前記１つまたは複数の要素のうちの要素は、３２ビットインデックスのデータ構造（Ｖ３２）を備え、そのレイアウトが、
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列の行および列を含む座標の１つまたは複数のペアとを含む、請求項２に記載の方法。
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列の行および列を含む座標の１つまたは複数のペアとを含む、請求項２に記載の方法。
【請求項4】
前記１つまたは複数の要素のうちの要素は、１６ビットインデックスのデータ構造（Ｖ１６）を備え、そのレイアウトは、
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む、請求項２または３に記載の方法。
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む、請求項２または３に記載の方法。
【請求項5】
前記１つまたは複数の要素のうちの要素は、８ビットインデックスのデータ構造（Ｖ８）を備え、そのレイアウトは、
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む、請求項２乃至４のいずれか一項に記載の方法。
前記データ構造の前記サイズおよび／またはタイプを表すタグと、
前記隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む、請求項２乃至４のいずれか一項に記載の方法。
【請求項6】
前記１つまたは複数の要素のうちの要素は、ｍビットインデックスのデータ構造（Ｖｍ）を備え、前記方法は、
前記要素に対応するタグを、前記座標の１つまたは複数のペアに基づいて決定するステップであって、前記タグは、データ構造の前記サイズおよび／またはタイプを表す、ステップをさらに含む、請求項２に記載の方法。
前記要素に対応するタグを、前記座標の１つまたは複数のペアに基づいて決定するステップであって、前記タグは、データ構造の前記サイズおよび／またはタイプを表す、ステップをさらに含む、請求項２に記載の方法。
【請求項7】
前記格納されたデータ構造は、前記隣接行列のそれぞれの小区分におけるＲＤＦタプルのグループのビットマップ表現のビット配列（ＢＭ）をさらに含む、請求項１乃至６のいずれか一項に記載の方法。
【請求項8】
前記格納されたデータ構造の前記配列は、サイズ２ｎ×２ｎの２次元配列またはサイズ２２ｎの１次元配列であり、ｎは正の整数である、請求項１乃至７のいずれか一項に記載の方法。
【請求項9】
前記データ構造を格納する前記ステップは、
スロットを割り当て、それにより、ルートインデックスを取得するステップであって、前記ルートインデックスはメモリ内の前記ツリーデータ構造の位置を表す、ステップと、
前記ルートインデックスにおける前記配列を座標ペアの配列に設定するステップと
を含む、請求項１乃至８のいずれか一項に記載の方法。
スロットを割り当て、それにより、ルートインデックスを取得するステップであって、前記ルートインデックスはメモリ内の前記ツリーデータ構造の位置を表す、ステップと、
前記ルートインデックスにおける前記配列を座標ペアの配列に設定するステップと
を含む、請求項１乃至８のいずれか一項に記載の方法。
【請求項10】
ＲＤＦグラフを格納する前記方法は、前記ＲＤＦグラフデータベース上で以下の関数、
前記隣接行列の所与のセルが第１の指定された値に設定されているかどうかをチェックするように構成された関数（Ｔｅｓｔ）、
前記隣接行列の所与のセルを第１の指定された値に設定するように構成された関数（Ｓｅｔ）、
前記隣接行列の所与のセルを第２の指定された値に設定するように構成された関数（Ｒｅｓｅｔ）、
第１の指定された値で前記隣接行列のすべてのセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＡｌｌ）、
第１の指定された値で前記隣接行列の所与の行のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＲｏｗ）、および／もしくは
第１の指定された値で前記隣接行列の所与の列のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＣｏｌｕｍｎ）
のうちの１つまたは複数を実装するステップをさらに含み、各関数は、前記１つまたは複数の隣接行列の各隣接行列に適用されるように構成される、請求項１乃至９のいずれか一項に記載の方法。
前記隣接行列の所与のセルが第１の指定された値に設定されているかどうかをチェックするように構成された関数（Ｔｅｓｔ）、
前記隣接行列の所与のセルを第１の指定された値に設定するように構成された関数（Ｓｅｔ）、
前記隣接行列の所与のセルを第２の指定された値に設定するように構成された関数（Ｒｅｓｅｔ）、
第１の指定された値で前記隣接行列のすべてのセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＡｌｌ）、
第１の指定された値で前記隣接行列の所与の行のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＲｏｗ）、および／もしくは
第１の指定された値で前記隣接行列の所与の列のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＣｏｌｕｍｎ）
のうちの１つまたは複数を実装するステップをさらに含み、各関数は、前記１つまたは複数の隣接行列の各隣接行列に適用されるように構成される、請求項１乃至９のいずれか一項に記載の方法。
【請求項11】
１つまたは複数の隣接行列を取得する前記ステップは、前記グラフデータベースの各述語について垂直分割を実行するステップを含む、請求項１乃至１０のいずれか一項に記載の方法。
【請求項12】
請求項１乃至１１のいずれか一項に記載の方法を実行するための命令を含むコンピュータプログラム。
【請求項13】
請求項１２に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体。
【請求項14】
メモリに結合されたプロセッサを備えたシステムであって、前記メモリが、請求項１２に記載のコンピュータプログラムを記録したシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、コンピュータプログラムおよびシステムの分野に関し、より具体的には、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するための方法、システム、およびプログラムに関する。
【背景技術】
【0002】
複数のシステムおよびプログラムが、オブジェクトの設計、エンジニアリング、および製造の市場に提供されている。ＣＡＤは、コンピュータ支援設計（Computer-Aided Design）の頭字語であり、例えば、オブジェクトを設計するためのソフトウェアソリューションに関する。ＣＡＥはコンピュータ支援エンジニアリング（Computer-Aided Engineering）の頭字語であり、例えば、将来の製品の物理的挙動をシミュレートするためのソフトウェアソリューションに関する。ＣＡＭはコンピュータ支援製造（Computer-Aided Manufacturing）の頭字語であり、例えば、製造処理および動作を定義するためのソフトウェアソリューションに関する。このようなコンピュータ支援設計システムでは、グラフィカルユーザインターフェースが技術の効率に関して重要な役割を果たす。これらの技術は、製品ライフサイクル管理（ＰＬＭ）システム内に組み込まれることがある。ＰＬＭとは、会社が、拡張された企業の概念にわたって、製品データを共有し、共通のプロセスを適用し、製品の開発について着想から寿命の終末まで企業知識を活用するのに役立つ事業戦略のことである。Ｄａｓｓａｕｌｔ Ｓｙｓｔｅｍｅｓによって（商標ＣＡＴＩＡ、ＥＮＯＶＩＡ、およびＤＥＬＭＩＡのもとに）提供されるＰＬＭソリューションは、製品エンジニアリング知識を編成するエンジニアリングハブ、製造エンジニアリング知識を管理する製造ハブ、およびエンジニアリングハブと製造ハブとの両方への企業の統合および接続を可能にする企業ハブを提供する。これらを合わせて、システムは、最適化された製品定義、製造準備、生産、およびサービスを促進する動的な知識ベースの製品作成および意思決定サポートを可能にするために、製品、プロセス、リソースをリンクするオープンオブジェクトモデルを提供する。
【0003】
さらに、ディスクまたはＳＳＤにデータを格納するデータベースとは対照的に、インメモリデータベース、すなわち、データ格納を主にメモリに依存する専用データベースにおいて、上記の設計システムおよびプログラムを適用するために、いくつかのデータベース管理用のソリューションが提供されている。そのようなデータベース管理ソリューションのうち、グラフデータベース、例えば、ＲＤＦグラフデータベースに関係付けられたソリューションは、データモデリングおよびデータ格納におけるそれらの柔軟性が大きいために特に興味深い。一般的なアプリケーションでは、ＲＤＦグラフデータベースは、数十億タプルでテラバイトのサイズの大きなデータセットを扱える必要がある（例えば、２０２２年５月１０日に非特許文献１から取得されたＭｉｃｒｏｓｏｆｔ Ａｃａｄｅｍｉｃ Ｋｎｏｗｌｅｄｇｅ Ｇｒａｐｈは、標準的ＴＴＬフォーマットで１．２ＴＢのストレージを必要とする８０億を超えるトリプルを有する）。当技術分野における既知のソリューションは、そのようなグラフのための（例えば、メモリ内またはディスク上の）ストレージの必要とされるサイズを低減するためのデータ圧縮技術（非特許文献２）を提案する。そのような圧縮技術は、様々な用途、特にクラウド展開において、ストレージコスト（例えば、ハードウェアコストなど）および環境フットプリントを削減するのに役立つ。
【0004】
非特許文献３は、圧縮空間におけるＳＰＡＲＱＬソリューションをサポートするＲＤＦインデックス技術を開示している。ｋ２トリプル（k2-triples）と呼ばれる開示された技術は、述語（predicate）を使用して、データセットを垂直に分割して、述語ごとに１つのペア（主語（subject）、目的語（object））の互いに素なサブセットを作る。これらのサブセットは、主語×目的語のバイナリ行列として表現され、そこでは、１ビットが、データセットに対応するトリプルが存在することを意味する。このモデルは、ｋ２ツリー（k2-trees）を使用して効率的に圧縮された非常に疎な行列をもたらす。
【0005】
非特許文献４は、グラフの特性を考慮し、四分木に基づいて圧縮を実行するアルゴリズムを開示している。さらに、データを圧縮すると共に、圧縮されたデータ自体に対してクエリを実行する技術が紹介され、詳細に論じられている。
【0006】
非特許文献５は、一時的な格納構造を使用せずにグラフを直接構築する圧縮されたバイナリツリーのインデックス付き配列に基づくストリーミンググラフのための新規なデータ構造の使用を開示している。このデータ構造は、エッジの存在（２つのノード間にエッジが存在するか？）、近傍クエリ（ノードの近傍を列挙する）、およびストリーミング操作（ノード／エッジの追加／削除）のための高速アクセス方法を提供する。
【0007】
この文脈において、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するための改良された方法が依然として必要である。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】欧州特許出願公開第２１３０６８３９．８号明細書
【非特許文献】
【0009】
【非特許文献1】ｈｔｔｐｓ：／／ｍａｋｇ．ｏｒｇ／ｒｄｆ－ｄｕｍｐｓ
【非特許文献2】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｄａｔａ＿ｃｏｍｐｒｅｓｓｉｏｎ
【非特許文献3】ＡＬＶＡＲＥＺ－ＧＡＲＣＩＡ，Ｓ．，ｅｔ ａｌ．，“Ｃｏｍｐｒｅｓｓｅｄ ｖｅｒｔｉｃａｌ ｐａｒｔｉｔｉｏｎｉｎｇ ｆｏｒ ｅｆｆｉｃｉｅｎｔ ＲＤＦ ｍａｎａｇｅｍｅｎｔ．”，Ｋｎｏｗｌｅｄｇｅ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ，２０１５，ｖｏｌ．４４，ｎｏ ２，ｐ．４３９－４７４
【非特許文献4】ＣＨＡＴＴＥＲＪＥＥ，Ａ．，ｅｔ ａｌ．，“Ｅｘｐｌｏｉｔｉｎｇ ｔｏｐｏｌｏｇｉｃａｌ ｓｔｒｕｃｔｕｒｅｓ ｆｏｒ ｇｒａｐｈ ｃｏｍｐｒｅｓｓｉｏｎ ｂａｓｅｄ ｏｎ ｑｕａｄｔｒｅｅｓ．”，Ｉｎ：２０１６ Ｓｅｃｏｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋｓ（ＩＣＲＣＩＣＮ）．ＩＥＥＥ，２０１６．ｐ．１９２－１９７
【非特許文献5】ＮＥＬＳＯＮ，Ｍ．，ｅｔ ａｌ．，“Ｑｕｅｒｙａｂｌｅ ｃｏｍｐｒｅｓｓｉｏｎ ｏｎ ｓｔｒｅａｍｉｎｇ ｓｏｃｉａｌ ｎｅｔｗｏｒｋｓ．”，Ｉｎ： ２０１７ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｂｉｇ Ｄａｔａ（Ｂｉｇ Ｄａｔａ）．ＩＥＥＥ，２０１７．ｐ．９８８－９９３
【非特許文献6】“ＲＤＦ １．１ Ｃｏｎｃｅｐｔｓ ａｎｄ Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ”，Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ２５ Ｆｅｂｒｕａｒｙ ２０１４（ｏｒ ａｄｄｉｔｉｏｎａｌｌｙ ｔｈｅ ｄｒａｆｔ ｖｅｒｓｉｏｎ ＲＤＦ－ｓｔａｒ）
【非特許文献7】“ＲＤＦ １．１ Ｎ－Ｑｕａｄｓ，Ａ ｌｉｎｅ－ｂａｓｅｄ ｓｙｎｔａｘ ｆｏｒ ＲＤＦ ｄａｔａｓｅｔｓ”，Ｗ３Ｃ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ２５ Ｆｅｂｒｕａｒｙ ２０１４
【非特許文献8】ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｒｄｆ－ｓｐａｒｑｌ－ｑｕｅｒｙ／＃ｒｄｆＤａｔａｓｅｔ
【非特許文献9】Ａｂａｄｉ，Ｄ．Ｊ．，ｅｔ ａｌ．，“Ｓｃａｌａｂｌｅ ｓｅｍａｎｔｉｃ ｗｅｂ ｄａｔａ ｍａｎａｇｅｍｅｎｔ ｕｓｉｎｇ ｖｅｒｔｉｃａｌ ｐａｒｔｉｔｉｏｎｉｎｇ．”，Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ３３ｒｄ ｉｎｔｅｒｎａｔｉｏｎａｌ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｖｅｒｙ ｌａｒｇｅ ｄａｔａｂａｓｅｓ，Ｓｅｐｔｅｍｂｅｒ ２００７，ｐｐ．４１１－４２２
【非特許文献10】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｑｕａｄｔｒｅｅ
【非特許文献11】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｄａｔａ＿ｃｏｍｐｒｅｓｓｉｏｎ
【非特許文献12】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｄｉｃｔｉｏｎａｒｙ＿ｃｏｄｅｒ
【非特許文献13】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｒａｄｉｘ＿ｔｒｅｅ＃ＰＡＴＲＩＣＩＡ
【非特許文献14】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｚ－ｏｒｄｅｒ＿ｃｕｒｖｅ
【非特許文献15】ＫＥＲＳＴＥＮ，Ｔ．，ｅｔ ａｌ．，“Ｅｖｅｒｙｔｈｉｎｇ ｙｏｕ ａｌｗａｙｓ ｗａｎｔｅｄ ｔｏ ｋｎｏｗ ａｂｏｕｔ ｃｏｍｐｉｌｅｄ ａｎｄ ｖｅｃｔｏｒｉｚｅｄ ｑｕｅｒｉｅｓ ｂｕｔ ｗｅｒｅ ａｆｒａｉｄ ｔｏ ａｓｋ．”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＶＬＤＢ Ｅｎｄｏｗｍｅｎｔ，２０１８，ｖｏｌ．１１，ｎｏ １３，ｐ．２２０９－２２２２
【非特許文献16】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｉｔｅｒａｔｏｒ
【非特許文献17】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｖｉｓｉｔｏｒ＿ｐａｔｔｅｒｎ
【非特許文献18】ｈｔｔｐｓ：／／ｅｎ．ｃｐｐｒｅｆｅｒｅｎｃｅ．ｃｏｍ／ｗ／ｃｐｐ／ｎｕｍｅｒｉｃ／ｒｏｔｌ
【非特許文献19】ｈｔｔｐｓ：／／ｅｎ．ｃｐｐｒｅｆｅｒｅｎｃｅ．ｃｏｍ／ｗ／ｃｐｐ／ｎｕｍｅｒｉｃ／ｐｏｐｃｏｕｎｔ
【非特許文献20】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍｅｍｏｒｙ＿ｍａｎａｇｅｍｅｎｔ＃ＨＥＡＰ
【非特許文献21】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｉｔｅｒａｔｏｒ＿ｐａｔｔｅｒｎ
【非特許文献22】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｂｒｅａｄｔｈ－ｆｉｒｓｔ＿ｓｅａｒｃｈ
【非特許文献23】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｍａｓｋ＿（ｃｏｍｐｕｔｉｎｇ）
【非特許文献24】ｈｔｔｐｓ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ－ｕｓ／ｒｅｓｅａｒｃｈ／ｐｒｏｊｅｃｔ／ｏｐｅｎ－ａｃａｄｅｍｉｃ－ｇｒａｐｈ／
【非特許文献25】ＢＲＩＳＡＢＯＡ，Ｎｉｅｖｅｓ Ｒ．ｅｔ ａｌ．“Ｃｏｍｐｒｅｓｓｅｄ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｏｆ ｄｙｎａｍｉｃ ｂｉｎａｒｙ ｒｅｌａｔｉｏｎｓ ｗｉｔｈ ａｐｐｌｉｃａｔｉｏｎｓ．”Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ，２０１７，ｖｏｌ．６９，ｐ．１０６－１２３
【非特許文献26】ｈｔｔｐｓ：／／ｗｗｗ．ｅｂｉ．ａｃ．ｕｋ／ｒｄｆ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ｃｈｅｍｂｌ／
【発明の概要】
【0010】
したがって、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するコンピュータ実装方法が提供される。この方法は、１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含むグラフデータベースのタプルのグループを表す、ステップを含む。この方法は、１つまたは複数の隣接行列の各々について、配列を含むデータ構造を格納するステップをさらに含む。配列は、各々が隣接行列の小区分を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む。
【0011】
この方法は、以下のうちの１つまたは複数を含み得る：
－ 配列の１つまたは複数の要素の各々は、１つまたは複数の座標ペアのセットを含み、各ペアは、隣接行列におけるそれぞれの座標を表す；
－ １つまたは複数の要素のうちの要素は、３２ビットインデックスのデータ構造を備え、そのレイアウトが、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列の行および列を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、１６ビットインデックスのデータ構造を備え、そのレイアウトは、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、８ビットインデックスのデータ構造を備え、そのレイアウトは、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、ｍビットインデックスのデータ構造を備え、この方法は、要素に対応するタグを、座標の１つまたは複数のペアに基づいて決定するステップをさらに含み、タグは、データ構造のサイズおよび／またはタイプを表す；
－ 格納されたデータ構造は、隣接行列のそれぞれの小区分におけるＲＤＦタプルのグループのビットマップ表現のビット配列（ＢＭ）をさらに含む；
－ 格納されたデータ構造の配列は、サイズ２ｎ×２ｎの２次元配列またはサイズ２２ｎの１次元配列であり、ｎは正の整数である；
－ データ構造を格納するステップは、スロットを割り当て、それにより、ルートインデックスを取得するステップであって、ルートインデックスはメモリ内のツリーデータ構造の位置を表す、ステップと、ルートインデックスにおける配列を座標ペアの配列に設定するステップとを含む；
－ ＲＤＦグラフを格納する方法は、ＲＤＦグラフデータベース上で以下の関数のうちの１つまたは複数を実装するステップをさらに含み、各関数は、１つまたは複数の隣接行列の各隣接行列に適用されるように構成される：
○ 隣接行列の所与のセルが第１の指定された値に設定されているかどうかをチェックするように構成された関数（Ｔｅｓｔ）、
○ 隣接行列の所与のセルを第１の指定された値に設定するように構成された関数（Ｓｅｔ）、
○ 隣接行列の所与のセルを第２の指定された値に設定するように構成された関数（Ｒｅｓｅｔ）、
○ 第１の指定された値で隣接行列のすべてのセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＡｌｌ）、
○ 第１の指定された値で隣接行列の所与の行のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＲｏｗ）、および／もしくは
○ 第１の指定された値で隣接行列の所与の列のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＣｏｌｕｍｎ）；ならびに／または
－ １つまたは複数の隣接行列を取得するステップは、グラフデータベースの各述語について垂直分割を実行するステップを含む。
－ 配列の１つまたは複数の要素の各々は、１つまたは複数の座標ペアのセットを含み、各ペアは、隣接行列におけるそれぞれの座標を表す；
－ １つまたは複数の要素のうちの要素は、３２ビットインデックスのデータ構造を備え、そのレイアウトが、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列の行および列を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、１６ビットインデックスのデータ構造を備え、そのレイアウトは、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、８ビットインデックスのデータ構造を備え、そのレイアウトは、データ構造のサイズおよび／またはタイプを表すタグと、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む；
－ １つまたは複数の要素のうちの要素は、ｍビットインデックスのデータ構造を備え、この方法は、要素に対応するタグを、座標の１つまたは複数のペアに基づいて決定するステップをさらに含み、タグは、データ構造のサイズおよび／またはタイプを表す；
－ 格納されたデータ構造は、隣接行列のそれぞれの小区分におけるＲＤＦタプルのグループのビットマップ表現のビット配列（ＢＭ）をさらに含む；
－ 格納されたデータ構造の配列は、サイズ２ｎ×２ｎの２次元配列またはサイズ２２ｎの１次元配列であり、ｎは正の整数である；
－ データ構造を格納するステップは、スロットを割り当て、それにより、ルートインデックスを取得するステップであって、ルートインデックスはメモリ内のツリーデータ構造の位置を表す、ステップと、ルートインデックスにおける配列を座標ペアの配列に設定するステップとを含む；
－ ＲＤＦグラフを格納する方法は、ＲＤＦグラフデータベース上で以下の関数のうちの１つまたは複数を実装するステップをさらに含み、各関数は、１つまたは複数の隣接行列の各隣接行列に適用されるように構成される：
○ 隣接行列の所与のセルが第１の指定された値に設定されているかどうかをチェックするように構成された関数（Ｔｅｓｔ）、
○ 隣接行列の所与のセルを第１の指定された値に設定するように構成された関数（Ｓｅｔ）、
○ 隣接行列の所与のセルを第２の指定された値に設定するように構成された関数（Ｒｅｓｅｔ）、
○ 第１の指定された値で隣接行列のすべてのセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＡｌｌ）、
○ 第１の指定された値で隣接行列の所与の行のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＲｏｗ）、および／もしくは
○ 第１の指定された値で隣接行列の所与の列のセルのそれぞれの座標を出力するように構成された関数（ＳｃａｎＣｏｌｕｍｎ）；ならびに／または
－ １つまたは複数の隣接行列を取得するステップは、グラフデータベースの各述語について垂直分割を実行するステップを含む。
【0012】
さらに、本方法を実行するための命令を含むコンピュータプログラムが提供される。
【0013】
さらに、コンピュータプログラムを記録したコンピュータ可読記憶媒体が提供される。
【0014】
さらに、メモリに結合されたプロセッサと、コンピュータプログラムを記録したメモリとを備えるシステムが提供される。
【図面の簡単な説明】
【0015】
次に、非限定的な例が添付図面を参照して説明される。
【図1】本方法の例のフローチャートである。
【図2】システムの例を示す図である。
【図3A】本方法による３２バイトデータ構造の例を示す図である。
【図3B】本方法による３２バイトデータ構造の例を示す図である。
【図4】本方法による１６バイトデータ構造の例を示す図である。
【図5】本方法による８バイトデータ構造の例を示す図である。
【図6A】最大容量に対するインデックスサイズの比較効果を示す図である。
【図6B】最大容量に対するインデックスサイズの比較効果を示す図である。
【発明を実施するための形態】
【0016】
図１のフローチャートを参照して、ＲＤＦタプルのセットを含むグラフデータベースにＲＤＦグラフデータを格納するコンピュータ実装方法が提案される。この方法は、１つまたは複数の隣接行列を取得するステップと、１つまたは複数の隣接行列の各々について、配列を含むデータ構造を格納するステップとを含む。各隣接行列は、同じ述語（predicate）を含むグラフデータベースのタプルのグループを表す。配列は、各々が隣接行列の小区分（sub-division）を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む。以下に詳細に論じられる方法の例では、この方法は、ツリーの中間ノードが２次元固定サイズ配列として見られ得るツリー状のデータ構造を提示することができる。この配列は、それぞれの葉を識別するための値を含むことができる。
【0017】
そのような方法は、まず、ＲＤＦグラフデータベースのタプルを表す１つまたは複数の隣接行列を取得する取得によって、ＲＤＦグラフデータベースを格納する際の改良された解決策を提供する。具体的には、各隣接行列が１つのグラフのみを表し得るので、タプルはトリプルであり得る。１つまたは複数の隣接行列のそのような取得が、データベースの垂直分割を構成する。それ自体知られているように、隣接行列は、主語、述語、および／または目的語の数に関係付けられたサイズのバイナリ行列（すなわち、２つの値、例えば、０および１を有する要素を持つ行列）であり、１ビットは、（例えば、隣接行列のそれぞれの述語の）対応するトリプルがＲＤＦデータセットに存在することを意味する。述語についての隣接行列のサイズは、述語のＲＤＦタプルの主語に目的語を乗じるサイズであり得る。第２に、本方法は、各インデックスが隣接行列の小区分を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素の配列を含むデータ構造として、１つまたは複数の隣接行列の各々を格納することによって、改良された解決策を提供する。そのような配列により、本方法は、各隣接行列の１つまたは複数の小区分に関係付けられたデータを格納することができる。それにより、本方法は、グラフデータベースにＲＤＦグラフデータを格納することを、効率的に隣接行列を圧縮するデータ構造をデータベースに格納することによって改善する。「グラフデータベースにＲＤＦグラフデータを格納すること」は、ＲＤＦグラフとしてモデル化されたデータ（すなわち、ＲＤＦデータセット）をグラフデータベースに格納することを意味する。ＲＤＦグラフは、それぞれのデータを表現／モデル化するデータの１つまたは複数のグラフであり得る。データベースおよびＲＤＦについては、以下でさらに説明される。他方で、本方法は、単に静的すなわち読取り専用メモリのために設計された方法とは対照的に、動的（すなわち、格納されたデータベース上で読取り／書込み操作ができる）を可能にしながら、そのような能力を提供する。
【0018】
本方法がツリー状データ構造を提示する例では、上述されたように、各中間ノードは２次元固定サイズ配列であり得る。中間ノードに対するそのような固定サイズ２次元配列は、データ構造に含まれる配列を少なくとも部分的に形成することができる。より具体的には、そのような固定サイズ２次元配列は、それぞれが隣接行列の小区分を指す１つまたは複数のインデックスを含むことができる。「データベース」は、検索および取出しのために編成されたデータ（すなわち情報）の任意のコレクション（例えば、グラフ指向データベース）を意味する。当技術分野で知られているように、グラフ指向データベースは、グラフ理論を使用したオブジェクト指向データベースであり、したがって、ノードおよび弧を有し、データが表現および格納されることを可能にする。グラフは、ストア内のデータアイテムを、ノードとエッジのコレクションに関係付け、エッジは、ノード間の関係を表している。この関係は、ストア内のデータが互いに直接リンクされることを可能にし、多くの場合、１つの操作でデータが取り出されることを可能にする。グラフデータベースは、暗黙の接続によってデータをリンクする他のデータベースモデル（例えば、リレーショナルデータベース）とは対照的に、データ間の関係を優先的に保持する。メモリ（例えば、永続メモリ）上に格納された場合、グラフデータベースは、コンピュータによる迅速な検索および取出しを可能にする。特に、グラフデータベースは、様々なデータ処理操作と関連して、関係の高速な取出し、修正、および削除をするために構造化されている。グラフ指向データベースはグラフデータベースとも呼ばれ、「グラフ指向データベース」と「グラフデータベース」という表現は同義語である。
【0019】
例では、グラフデータベースはＲＤＦグラフデータベースであり得る。ＲＤＦグラフは、グラフの格納および取出しに使用される従来のデータモデルである。ＲＤＦグラフは、有向のラベル付きグラフデータフォーマットである。そのようなフォーマットは、ウェブにおいて情報を表現するために広く使用されている。グラフとして情報のＲＤＦ表現を指定するための標準仕様がＷ３Ｃによって公表されている（例えば、非特許文献６参照）。ＲＤＦグラフデータベースは何十億のタプルを有することがあり、例えば、Ｕｎｉｐｒｏｔデータセットはタンパク質配列および機能情報のリソースである。
【0020】
使用される抽象構文のコア構造は、タプルのセットであり、各タプルは述語を含む。そのようなＲＤＦタプルのセットはＲＤＦグラフと呼ばれる。
【0021】
例では、ＲＤＦタプルは、ノードおよびエッジを含む３つまたは４つの要素を含むことがある。例では、各ＲＤＦタプル（または各ＲＤＦタプルの要素）は、主語、述部、および目的語を含むトリプルであり得る。そのような例では、ＲＤＦグラフは、ノードおよび有向弧図として視覚化されてよく、そこでは、各トリプルは、ノード－弧－ノードリンクとして表される。あるいは、ＲＤＦトリプルは、主語と目的語である２つのノードと、それらを接続する述語である弧によって視覚化されてよい。
【0022】
例では、ＲＤＦタプルは、ＲＤＦクワッドであり得る。ＲＤＦクワッドは、ＲＤＦトリプルにグラフラベルを加えることによって得られる場合がある。そのような例では、ＲＤＦタプルはＲＤＦグラフを含む。ＲＤＦクワッド（Ｎ－Ｑｕａｄｓとも呼ばれる）を指定するための標準仕様がＷ３Ｃによって公表されている（例えば、非特許文献７参照）。ＲＤＦクワッドは、ＲＤＦトリプルにグラフ名を追加することで得られる場合がある。グラフ名は、空（すなわち、デフォルトもしくは無名グラフ）またはＩＲＩ（すなわち、グラフＩＲＩのいずれかであってよい。例では、グラフの述語はグラフＩＲＩと同じＩＲＩを有することがある。各クワッドのグラフ名は、それぞれのＲＤＦデータセットにおいてそのクワッドが部分であるグラフである。ＲＤＦデータセットは、それ自体知られているように、グラフのコレクションを表す（例えば、非特許文献８参照）。以下では、ＲＤＦタプル（またはタプル）という用語は、一方または他方の使用が明示的に言及されていない限り、ＲＤＦトリプルまたはＲＤＦクワッドを無差別に指す。
【0023】
グラフデータベースのクエリエンジンについて可能な最適化は、グラフデータベースが開世界（Open World）または閉世界（Closed World）と相互作用しているという仮定に影響される。それ自体知られているように、知識表現に使用される論理の形式的システムにおいて、開世界仮説（ＯＷＡ）とは、文の真理値は、それが真であると知られているかどうかにかかわらず真であり得るという仮定である。これは、真であるいかなる文も真であることが知られていることが成り立つ閉世界仮説の逆である。他方で、閉世界システムでは、すべてのものを配置するために場所を必要とする（例えば、フレーム上のスロット、ＯＯクラス上のフィールド、またはＤＢ内の列）。ＯＷＡは、デフォルトで不完全な情報を仮定しており、意図的に不完全な指定をして、他者が再利用および拡張することを可能にする。セマンティックウェブは、再利用可能な形式の分散された知識およびデータである、コンピュータに理解可能なウェブの構想であり、ＲＤＦは、セマンティックウェブについてのＷ３Ｃ勧告であり、開世界仮説に従っている。それは、データモデル化およびデータ格納における柔軟性を高めることを可能にする。しかし、ＳＱＬを用いた関係モデルと同様に、閉世界仮説の制約は、どのようにデータが格納されるかについてより多くの情報を提供するので、クエリ最適化にとって有用である。例では、クエリはＳＰＡＲＱＬクエリである。ＳＰＡＲＱＬは、ＲＤＦデータの問い合わせについてのＷ３Ｃ勧告であり、ＲＤＦトリプルのパターン上に構築されたグラフマッチング言語である。「ＲＤＦタプルのパターン」は、ＲＤＦグラフによって形成されるパターン／テンプレートを意味する。言い換えれば、ＲＤＦタプルのパターンは、ＲＤＦグラフ（すなわち、ＲＤＦトリプルのセット）であり、そこでは、グラフの主語、述部、目的語、またはラベルが（クエリのための）変数で置き換えられることが可能である。ＳＰＡＲＱＬは、データがＲＤＦとしてネイティブに格納されるか、またはミドルウェアを介してＲＤＦとして見られるかにかかわらず、多様なデータソースわたってクエリを表現することができるＲＤＦデータ用のクエリ言語である。ＳＰＡＲＱＬは主にグラフ準同型に基づいている。グラフ準同型は、２つのグラフの間のそれらの構造を尊重するマッピングである。より具体的には、隣接する頂点を隣接する頂点に対してマッピングする、２つのグラフの頂点セット間の関数である。
【0024】
ＳＰＡＲＱＬは、必要とされるグラフパターンおよび任意選択のグラフパターンをそれらの論理積および論理和と共に問い合わせる能力を含む。ＳＰＡＲＱＬはまた、集約、サブクエリ、否定、式による値の生成、拡張可能な値テスト、およびソースＲＤＦグラフによるクエリの制約もサポートする。これは、ＳＰＡＲＱＬクエリが、ＳＰＡＲＱＬにおいて可能な８つの異なるトリプルパターンに対して応答する必要があることを意味する。そのような８つのトリプルパターンは、（Ｓ，Ｐ，Ｏ）、（Ｓ，？Ｐ，Ｏ）、（Ｓ，Ｐ，？Ｏ）、（Ｓ，？Ｐ，？Ｏ）、（？Ｓ，Ｐ，Ｏ）、（？Ｓ，？Ｐ，Ｏ）、（？Ｓ，Ｐ，？Ｏ）、および（？Ｓ，？Ｐ，？Ｏ）を含み、パターンにおいて変数に記号？が先行する。変数は、トリプルパターンの出力であり、ＳＰＡＲＱＬクエリの出力であり得る。いくつかの例では、変数は、ＳＥＬＥＣＴクエリの出力であり得る。ＳＰＡＲＱＬクエリの出力は、変数（例えば、合計などのアグリゲータ）を使用して構築され得る。クエリにおける変数は、グラフ準同型（すなわち、クエリの結果を得るために必要な中間ノード）を構築するために使用され得る。いくつかの例では、クエリにおける変数は、出力にも中間結果にも使用されなくてよい。基本グラフパターン（ＢＧＰ）は、上記で説明された８つのトリプルパターンのうちの１つであってよい。さらに、ＢＧＰは、クエリ変数としてグラフのラベルをさらに有するクワッドパターンであってもよい。本方法がタプルのグループの表現として１つまたは複数の隣接行列をそれぞれ取得する特定の例では、主語と目的語が１つの隣接行列上で問い合わされ得る。言い換えれば、これらの特定の例では、ＢＧＰは、（Ｓ，Ｏ）、（Ｓ，？Ｏ）、（？Ｓ，Ｏ）、および（？Ｓ，？Ｏ）のいずれかであり得る。ＳＰＡＲＱＬは、いくつかのＢＧＰおよび場合によっては他の演算子の結果を結合することによって、より複雑なクエリを構築し得る。したがって、競争力のあるＳＰＡＲＱＬエンジンは、少なくとも、高速なトリプルパターン解法および効率的な結合方法を必要とする。さらに、ＢＧＰにおいて結合される中間結果の量を最小化する効率的な実行プランを構築するために、クエリオプティマイザが必要とされる。
【0025】
例では、グラフデータベースが既存のトリプルストアを有する。トリプルストア（ＲＤＦストアとも呼ばれる）は、当技術分野で知られているように、セマンティッククエリを介したトリプルの格納および取出しのための専用データベースである。トリプルストアは、少なくとも、上述されたＳＰＡＲＱＬの８つの基本トリプルパターンに対して応答することができる。それは、トリプルパターンと共にフィルタリング制約（例えば、「ｘ＞５」）にも応答し得る。そのようなトリプルストアは、クエリエンジンによりＳＰＡＲＱＬクエリが実行されるストレージエンジンであると考えられる。ストレージエンジン（「データベースエンジン」とも呼ばれる）は、当技術分野で知られているように、データベースからデータの作成（Create）、読取り（Read）、更新（Update）および削除（Delete）（ＣＲＵＤ）をするためにデータベース管理システム（ＤＢＭＳ）が使用する基本的ソフトウェアコンポーネントである。
【0026】
図１に戻ると、ステップＳ１０において、本方法は、１つまたは複数の隣接行列を取得するステップであって、各隣接行列は、同じ述語を含むグラフデータベースのタプルのグループを表す、ステップを含んでいる。例では、１つまたは複数の隣接行列を取得するステップは、グラフデータベースの各述語について垂直分割を実行するステップを含む。本方法は、当分野で知られているように、例えば、非特許文献９に説明されているように、垂直分割を実行することができる。垂直分割を実行することによって１つまたは複数の隣接行列を取得するステップは、グラフデータベースを取得するステップ、および取得されたグラフデータベース上で垂直分割を実行するステップを含むことができる。「グラフデータベースを取得するステップ」は、このデータベースを本方法に提供することを意味する。例では、そのような取得することまたは提供することは、データベースを（例えば、オンラインデータベースもしくはオンラインクラウドから）ダウンロードすること、またはこのデータベースをメモリ（例えば、永続メモリ）から取り出すことのいずれかを意味することができるか、または含むことができる。
【0027】
ステップＳ２０において、本方法は、１つまたは複数の隣接行列の各々について、配列を含むデータ構造を格納する。例では、格納されたデータの配列は、サイズ２ｎ×２ｎの２次元配列またはサイズ２２ｎの１次元配列であり、ｎは正の整数である。特定の例では、ｎの値は２に等しいことがある。このｎの選択により、現代のプロセッサのキャッシュラインサイズに容易に合わせられる比較的小さいサイズのノードを作り、それによって、キャッシュラインに適合されるデータ構造の適用を改善する。さらに、そのような選択は、ｎ＝１の場合のｌｏｇ４の複雑さではなくｌｏｇ１６の複雑さを有するアルゴリズム（後述されるようなＴｅｓｔ、Ｓｅｔ、Ｒｅｓｅｔなど）を提供する。
【0028】
例では、データ構造を格納するステップが、スロットを割り当て、それにより、ルートインデックスを取得するステップを含むことができる。ルートインデックスはメモリ内のツリーデータ構造の位置を表す。格納するステップは、ルートインデックスにおける配列を座標ペアの配列に設定するステップをさらに含むことができる。言い換えれば、これらの例によれば、（下記で説明される）タイプＶ３２の空のルートノードと共に空のデータ構造が（例えば、メモリ内に）作成されてよく、一方、この第１のノードの位置は、本方法がメモリ内でこの第１のノードの位置を特定することが可能なように、「ルートインデックス」によって表される。
【0029】
上記に論じられたように、格納された配列は、各々が隣接行列の小区分を指す１つもしくは複数のインデックス、および／または各々が隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループを表す１つもしくは複数の要素を含む。言い換えれば、格納された配列は、各隣接行列の小区分の相対的位置を定義するインデックス、および／または隣接行列のそれぞれの小区分のＲＤＦグラフデータベースのタプルのグループの直接的表現を格納することができる。例では、１つまたは複数のインデックスの各々が３２ビットサイズであってよい。そのような例では、上述された正の整数ｎの値が２に等しいとき、格納された配列は、２ｎ×２ｎ×３２ビット＝６４バイトの最大サイズとなる。そのような格納された配列は、後述されるツリー状構造で同等に呼ばれることがある。
【0030】
例では、本方法による格納されたデータベースは、各隣接行列を表すように構成されたツリー状データ構造を表すことができる。そのような例では、データ構造は、１つまたは複数のノードを含むことができ、ここで、各ノードは、１つもしくは複数のノードおよび／または１つもしくは複数の葉に接続されている。ツリー状データ構造は、四分木データ構造である（それに類似する）ことがある。四分木は、各内部ノードが正確に４つの子を有するツリーデータ構造である。四分木は、八分木の２次元アナログであり、ほとんどの場合、２次元空間を４つの象限または領域に再帰的に細分化することによって分割するために使用される（非特許文献１０参照）。
【0031】
例では、本方法は、ＲＤＦグラフデータベース上で以下の関数のうちの１つまたは複数を実装するステップをさらに含むことができる。以下の関数の各々は、１つまたは複数の隣接行列の各隣接行列に適用されるように構成され得る：隣接行列の所与のセルが第１の指定された値に設定されているかをチェックするように構成された（「Ｔｅｓｔ」関数と呼ばれる）関数、隣接行列の所与のセルを第１の指定された値に設定するように構成された（「Ｓｅｔ」関数と呼ばれる）関数、隣接行列の所与のセルを第２の指定された値に設定するように構成された（「Ｒｅｓｅｔ」関数と呼ばれる）関数、第１の指定された値で隣接行列のすべてのセルのそれぞれの座標を出力するように構成された（「ＳｃａｎＡｌｌ」関数と呼ばれる）関数、第１の指定された値で隣接行列の所与の行のセルのそれぞれの座標を出力するように構成された（「ＳｃａｎＲｏｗ」関数と呼ばれる）関数、および／または第１の指定された値で隣接行列の所与の列のセルのそれぞれの座標を出力するように構成された（「ＳｃａｎＣｏｌｕｍｎ」と呼ばれる）関数。
【0032】
例では、配列の１つまたは複数の要素の各々は、１つまたは複数の座標ペアのセットを含み、各ペアは、隣接行列におけるそれぞれの座標を表す。隣接行列におけるそれぞれの座標のそのような表現は、（例えば、Ｖ３２サブタイプにおける）座標の直接的表現であってよく、または（例えば、ベースおよびベースに対するオフセットを使用する、Ｖ１６およびＶ８における）座標の間接的表現であってもよい。
【0033】
上述された要素のメモリレイアウトの例がここで論じられる。「メモリレイアウト」または「レイアウト」は、データがメモリまたはファイルに格納される組織的な様式を意味する。本明細書で以下に論じられるように、メモリレイアウトの各例（または種類）は、メモリレイアウトの別の例とは異なるサイズのインデックス、例えば３２、１６、または８ビットのインデックスを使用してよい。各インデックスは、座標のペアにおける１つの座標に関連付けられ得る。格納されたデータ構造がツリーデータ構造（例えば、四分木データ構造）を表す例では、メモリレイアウトの各種類は、ツリーにおける葉ノードの種類を表し得る。格納されたデータベースに異なるメモリレイアウト（各々が異なるインデックスサイズを有する）を統合することは、格納されたデータ構造（または同等に、対応するツリーの葉ノード）を、挿入されたデータのボリューム（すなわちサイズ）に適合させ、したがって、スペース効率を犠牲にすることなく良好なクエリ時間を維持することによって、グラフデータをグラフデータベースに格納するための改良された解決策を構成する。本方法は、順序に従って、例えば、当分野で知られているように、モートン順序（またはモートン符号／エンコード）に基づいて、最適化された挿入順序に従って、データ構造を格納するための順序付けを設定することができる。モートン符号化による挿入（すなわち、主語および目的語の挿入）は、中間ノードの修正の回数を最小限にする。
【0034】
例では、１つまたは複数の要素のうちの要素は、Ｖ３２レイアウトと呼ばれるレイアウトを有する３２ビットインデックスのデータ構造を備える。各３２ビットインデックスは３２ビットのサイズである。サイズは、本明細書では、幅またはビットフィールド幅と同等に呼ばれることがある。「３２ビットインデックスのデータ構造」は、各々がインデックスの役割をする複数の３２ビット整数のベクトル／配列を含むデータ構造を意味する。Ｖ３２レイアウトは、特に、隣接行列の行および列を含む座標の１つまたは複数のペアを含み得る。そのような場合、３２ビットインデックスの各々は、座標のペアにおける座標であり、すなわち、インデックスは隣接行列の行または列を表す。さらに言い換えれば、各行インデックスは３２ビットのサイズであり、各列インデックスは３２ビットのサイズである。
【0035】
Ｖ３２レイアウトは、データ構造の最大サイズを示す固定最大容量または同等の複数の整数の数によってさらに定義され得る。例では、レイアウトのサイズは、例えば上述のような（１次元／２次元）配列の形式で、格納された１つまたは複数のインデックスのサイズ（すなわち、中間ノードのサイズ）よりも小さくてよい。
【0036】
いくつかの例では、Ｖ３２レイアウトは、データ構造のサイズおよび／または（固定最大サイズに対応する）最大サイズ（すなわち、データ構造を表すベクトル）を表すタグを含むことができる。タグはさらに、データ構造のタイプ（すなわち、Ｖ３２タイプ）を表すことができる。あるいは、本方法は、要素に対応するタグを決定することができる。例えば、ツリー状構造において、本方法は、ツリー内の要素に対するそれぞれのノードのそれぞれの深さに基づいて、タグを決定することができる。そのような代替形態は、タグをＶ３２レイアウト（例えばヘッダ）に格納するために割り当てられたサイズを解放し、それにより、必要なストレージの最適化と同等であるレイアウトの最大容量の増加をすることによって、さらに改良された解決策を構成する。
【0037】
図３Ａおよび図３Ｂを参照して後述されるＶ３２データ構造の例では、格納される配列のサイズは６４バイトであり、メモリレイアウトは、第１の行に格納されるメタデータ（すなわち、ＶＥＣＴＯＲ＿ＬＥＡＦ、Ｖ３２ＴＡＧ、サイズ（size）、最大サイズ（maxSize））のために８バイトを予約する。それにより、メモリレイアウトは、各ペアが６４ビットである７つまでのペアの座標を格納することができる。
【0038】
例では、１つまたは複数の要素の要素は、Ｖ１６レイアウトと呼ばれるレイアウトを有する１６ビットインデックスサイズのデータ構造を備える。各１６ビットインデックスは１６ビットのサイズであってよい。上述されたように、「１６ビットインデックスのデータ構造」は、各々がインデックスの役割をする複数の１６ビット整数のベクトル／配列を含むデータ構造を意味する。Ｖ１６レイアウトは、特に、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアを含み得る。そのような場合、１６ビットインデックスの各々は、座標のペアにおける１つの座標を表し、すなわち、隣接行列のベース列、ベース行、オフセット列、またはオフセット行を表す。さらに言い換えれば、ベース列インデックス、ベース行インデックス、オフセット列インデックス、およびオフセット行インデックスの各々は、１６ビットのサイズである。
【0039】
Ｖ１６レイアウトは、データ構造の最大サイズを示す固定最大容量または同等の複数の整数の数によってさらに定義され得る。Ｖ１６レイアウトの最大容量は、上述されたＶ３２レイアウトの最大容量と同じであり得る。
【0040】
いくつかの例では、Ｖ１６レイアウトは、データ構造のサイズおよび／または（固定最大サイズに対応する）最大サイズを表すタグを含むことができる。タグはさらに、データ構造のタイプ（すなわち、Ｖ１６タイプ）を表すことができる。あるいは、本方法は、要素に対応するタグを決定することができる。例えば、ツリー状構造において、本方法は、ツリー内の要素に対するそれぞれのノードのそれぞれの深さに基づいて、タグを決定することができる。Ｖ３２に関して上述されたように、そのような代替形態が改良された解決策を構成する。
【0041】
図４を参照して後述されるＶ１６データ構造の例では、メモリレイアウトは、２４ペアまでの座標および／または２８×２８サイズの変換された部分行列内に制約され得る座標のペアのそれぞれの値を格納することができる。メモリレイアウトは、１３ペアまでの座標および／または２１６×２１６サイズの変換された部分行列内に制約され得る座標のペアのそれぞれの値を格納することができる。言い換えれば、変換された部分行列の場合、座標ペアｒｎ，ｃｎは（Ｒｂａｓｅ＊２１６）＋Ｒｏｎ，（Ｃｂａｓｅ＊２１６）＋Ｃｏｎとして計算される。ここで、ＲｏｎおよびＣｏｎは１６ビットに制約され、すなわち、ＲｏｎおよびＣｏｎは、０と２１６－１との間である。さらに、部分行列変換は、２ｘアライメントされる。
【0042】
例では、１つまたは複数の要素のうちの要素は、Ｖ８レイアウトと呼ばれるレイアウトを有する８ビットインデックスのデータ構造を備える。各８ビットインデックスは８ビットのサイズである。上述されたように、「８ビットインデックスのデータ構造」は、各々がインデックスの役割をする複数の８ビット整数のベクトル／配列を含むデータ構造を意味する。Ｖ８レイアウトは、特に、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアを含み得る。Ｖ８レイアウトの各葉について、１つのベース行、１つのベース列、ならびに１つまたは複数のオフセット行およびオフセット列ペアがある。そのような場合、８ビットインデックスの各々は、座標のペアにおける１つの座標を表し、すなわち、隣接行列インデックスのベース列、ベース行、オフセット列、またはオフセット行を表す。さらに言い換えれば、ベース列インデックス、ベース行インデックス、オフセット列インデックス、およびオフセット行インデックスの各々は、８ビットのサイズである。
【0043】
Ｖ８レイアウトは、データ構造の最大サイズを示す固定最大容量、または同等の複数の整数の数によってさらに定義され得る。Ｖ８レイアウトの最大容量は、上述されたＶ３２およびＶ１６レイアウトの最大容量と同じであり得る。
【0044】
いくつかの例では、Ｖ８レイアウトは、データ構造のサイズおよび／または（固定最大サイズに対応する）最大サイズを表すタグを含むことができる。タグはさらに、データ構造のタイプ（すなわち、Ｖ８タイプ）を表すことができる。あるいは、本方法は、要素に対応するタグを決定することができる。例えば、ツリー状構造において、本方法は、ツリー内の要素に対するそれぞれのノードのそれぞれの深さに基づいて、タグを決定することができる。Ｖ３２およびＶ１６に関して上述されたように、そのような代替形態が改良された解決策を構成する。
【0045】
図５を参照して後述されるＶ８データ構造の例では、Ｖ８レイアウトは、データ構造のサイズを表すタグと、隣接行列のベース列、ベース行、オフセット列、およびオフセット行を含む座標の１つまたは複数のペアとを含む。Ｖ８レイアウトの各葉について、１つのベース行、１つのベース列、ならびに１つまたは複数のオフセット行およびオフセット列ペアがある。Ｖ１６の場合で説明したように、Ｖ８では、座標のペアのそれぞれの値は、２８×２８サイズの変換された部分行列内に制約され得る。
【0046】
具体的には、Ｖ３２、Ｖ１６、およびＶ８レイアウトは、同じ最大容量を有する同じパターンの変形、すなわち、Ｖ＜ｎｎ＞、ここで、ｎｎは３２、１６、または８と考えられ得る。パラメータｎｎは単にｍと表示されてもよい。３２、１６、および８以外のｎｎの他の値が使用されてもよい。Ｖ＜ｎｎ＞は座標のベクトルであり、１つまたは複数の座標オフセットがｎｎビットを使用して格納され、ベース座標が３２－ｎｎビットを使用して格納される。３２ビット座標は、（すなわち、ビット単位演算（ｂａｓｅ＜＜ｎｎ）｜ｏｆｆｓｅｔに従って、）ベースとオフセットを組み合わせることによって抽出される。Ｖ＜ｎｎ＞レイアウトの例では、行と列のペア（それぞれ３２ビットインデックス）が与えられると、行および列の最下位ｎｎビットがオフセットとして格納されると共に、行および列の上位ビットが共有される（すなわち、ベース）。Ｖ３２レイアウトの場合、共有すべきビットが０であるため、上位ビットを格納する必要がない。
【0047】
ｎｎがデータ構造に格納されるインデックスのビットである、一般的なＶ＜ｎｎ＞タイプの例では、データ構造は、上述されたＶ３２、Ｖ１６、およびＶ８の例と同じサイズ、最大サイズ、および／またはデータ構造のタイプ（すなわち、Ｖ＜ｎｎ＞タイプまたはｎｎの値）を表すタグをさらに含むことができる。あるいは、本方法は、要素に対応するタグを決定することができる。（上述されたＶ３２、Ｖ１６、およびＶ８のいずれにも適用可能な）例では、タグの決定は座標のペアに基づいてよい。例では、本方法は、ノードによって保持できる変換された部分行列のサイズ、および／またはノードに格納されるべき座標のペアの数によって、タグを決定することができる。例えば、ツリー状構造において、本方法は、（上記された変換された部分行列および／または格納されるべき座標のペアの数に関係付けられ得る）ツリー内の要素に対するそれぞれのノードのそれぞれの深さに基づいて、タグを決定することができる。上述されたように、そのような代替形態は、タグを（例えばヘッダに）格納するために割り当てられたサイズを解放し、それにより、必要なストレージの最適化と同等であるレイアウトの最大容量の増加をすることによって、さらに改良された解決策を構成する。
【0048】
上述された例のいずれかと組み合わせ可能な例では、格納されたデータ構造は、隣接行列のそれぞれの小区分におけるＲＤＦタプルのグループのビットマップ表現のビット配列をさらに含むことができる。それ自体知られているように、「ビットマップ」は、整数などの１つのシステムからビットへのマッピングを意味する。それは、ビットマップインデックスまたはビット配列としても知られている。これは、ビットマップ表現がより小さなサイズで１つまたは複数の要素の表現を形成するため、改良された解決策を構成する。したがって、ビット配列を含む本方法の例は、メモリコストをさらに最適化する。
【0049】
本方法は、コンピュータに実装される。これは、本方法のステップ（または実質的にすべてのステップ）が、少なくとも１つのコンピュータまたは任意の同様のシステムによって実行されることを意味する。したがって、本方法のステップは、コンピュータによって、場合によっては完全に自動的に、または半自動的に実行される。例では、本方法の少なくともいくつかのステップのトリガは、ユーザとコンピュータの対話を通じて実行され得る。必要とされるユーザとコンピュータの対話のレベルは、予測される自動化のレベルに応じ得、ユーザの希望を実装する必要性とバランスがとられてよい。例では、このレベルはユーザ定義および／または事前定義され得る。
【0050】
方法のコンピュータ実装の典型的な例は、この目的に適合されたシステムで方法を実行することである。システムは、メモリおよびグラフィカルユーザインターフェース（ＧＵＩ）に結合されたプロセッサを備えることができ、メモリは、本方法を実行するための命令を含むコンピュータプログラムを記録している。メモリはデータベースを格納することもできる。メモリは、そのような格納に適合された任意のハードウェアであり、場合によっては、いくつかの物理的に異なる部品（例えば、プログラム用に１つ、および場合によってはデータベース用に１つ）を備える。
【0051】
図２は、システムの例を示し、システムは、クライアントコンピュータシステム、例えば、ユーザのワークステーションである。
【0052】
この例のクライアントコンピュータは、内部通信バス１０００に接続された中央処理装置（ＣＰＵ）１０１０、さらにバスに接続されたランダムアクセスメモリ（ＲＡＭ）１０７０を含む。クライアントコンピュータは、バスに接続されたビデオランダムアクセスメモリ１１００に関連付けられたグラフィック処理装置（ＧＰＵ）１１１０がさらに設けられている。ビデオＲＡＭ１１００は、当技術分野でフレームバッファとしても知られている。マスストレージデバイスコントローラ１０２０は、ハードドライブ１０３０などのマスメモリデバイスへのアクセスを管理する。コンピュータプログラム命令およびデータを有形に具現化するのに適したマスメモリデバイスは、すべての形態の不揮発性メモリを含み、例として、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクおよび取外し可能ディスクなどの磁気ディスク、ならびに光磁気ディスクを含む。上記のいずれも、特別に設計されたＡＳＩＣ（特定用途向け集積回路）に補完され、または組み込まれ得る。ネットワークアダプタ１０５０は、ネットワーク１０６０へのアクセスを管理する。クライアントコンピュータは、カーソル制御デバイスまたはキーボードなどのハプティックデバイス１０９０を含むこともできる。カーソル制御デバイスは、クライアントコンピュータにおいて、ユーザがディスプレイ１０８０上の任意の所望の位置にカーソルを選択的に配置できるように使用される。加えて、カーソル制御デバイスは、ユーザが様々なコマンドを選択し制御信号を入力することを可能にする。カーソル制御デバイスは、システムに制御信号を入力するためのいくつかの信号生成デバイスを含む。典型的には、カーソル制御デバイスはマウスであり、マウスのボタンが、信号を生成するために使用されることがある。代替的または追加的に、クライアントコンピュータシステムは、センシティブパッドおよび／またはセンシティブスクリーンを備えることができる。
【0053】
コンピュータプログラムは、コンピュータによって実行可能な命令を含むことができ、命令は、上記システムに本方法を実行させるための手段を含む。プログラムは、システムのメモリを含む任意のデータ記憶媒体に記録可能であり得る。プログラムは、例えば、デジタル電子回路、もしくはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせに実装され得る。プログラムは、装置として、例えば、プログラマブルプロセッサによる実行のために機械可読ストレージデバイスに有形に具現化された製品として実装され得る。方法ステップは、入力データを操作して出力を生成することによって本方法の機能を実行する命令のプログラムをプログラム可能なプロセッサが実行することによって実行され得る。したがって、プロセッサは、データストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータおよび命令を受信し、またそれらにデータおよび命令を送信するように、プログラム可能に結合され得る。アプリケーションプログラムは、高水準手続きプログラミング言語もしくはオブジェクト指向プログラミング言語で、または必要に応じてアセンブリ言語もしくは機械言語で実装され得る。いずれの場合も、言語はコンパイル言語またはインタプリタ言語であり得る。プログラムは、完全インストールプログラムまたは更新プログラムであり得る。いずれの場合も、システムへのプログラムの適用が、本方法を実行するための命令をもたらす。あるいは、コンピュータプログラムは、クラウドコンピューティング環境のサーバに格納され実行されてもよく、サーバは、１つまたは複数のクライアントとネットワークを介して通信する。そのような場合、処理ユニットは、プログラムに含まれる命令を実行し、それにより、クラウドコンピューティング環境上で本方法が実行されるようにする。
【0054】
ここで、本方法の上述された例の実装が論じられる。
【0055】
実装は、非常に大きなデータセットを扱える必要があるＲＤＦデータベースに関係付けられる。ＲＤＦはナレッジグラフを表現するためのＷ３Ｃ標準である。ナレッジグラフは、何十億個ものトリプルを有することができる（例えば、ＭＡＧ、Ｕｎｉｐｒｏｔ）。利用可能なＲＤＦデータの量の爆発的な増大、および結果としてのグラフデータベースのサイズの増大が、そのようなデータソースを探索、問い合わせ、理解する必要性をもたらしている。
【0056】
そのようなグラフの格納サイズを（メモリ内またはディスク上で）縮小することは、クラウド展開におけるコストおよび環境フットプリントを低減するために重要である。そのため、データ圧縮（非特許文献１１参照）、より正確にはグラフの圧縮（すなわち、ＲＤＦトリプルによって表現されるグラフデータの圧縮）が、実装を活用する際に重要な概念となる。
【0057】
実装は、グラフを表現するために垂直分割を使用することを含む。この方式を使用したＲＤＦグラフの表現では、各述語はそれ自体がグラフであり、このとき、主語および目的語がノードであり、述語がエッジである、表現となる。これらのグラフは、ｎ個の隣接行列と見なされ得る。したがって、グラフを圧縮することは、効率的に圧縮された隣接行列に対するデータ構造を使用することを意味する。この方向において、実装はさらに、入力値がデータ圧縮の最初のステップとして整数キーに符号化される辞書符号化（非特許文献１２参照）を含む。これは、隣接行列が文字列の代わりに整数を操作することを意味する。
【0058】
実装は、非常に大きなＲＤＦグラフを圧縮する目的で整数の隣接行列を表すために使用されるデータ構造の分野に特に関係付けられる。これは、スペース効率的なグラフ表現の分野で行われる。実装において、グラフ（すなわちグラフデータベース）は、特に動的なことがあり、それは修正されることが可能であり、読取り専用ではないことを意味する。実装による格納されたデータベースは、データベースに格納されたデータを解凍することなく問い合わされ得る。
【0059】
より具体的には、実装は、非常に大きな行列にスケールする整数の隣接行列として表現される動的ＲＤＦグラフのスペース効率的な表現を提供する。これは、そのような格納されたグラフデータベースの走査の経過時間が悪化せず、（読取り最適化されたデータ構造と比較して）表現が依然としてスペース効率的であることを意味する。
【0060】
特に実装は、ＸＡＭＴｒｅｅと呼ばれるデータ構造を開示し、これは（２次元スペースを４つの象限に細分化することにより分割するという意味で）四分木データ構造の一般的分野で行われ、非特許文献３に記載されているＫ２－Ｔｒｅｅのようなパトリシアトライ（非特許文献１３参照）のいくつかの特徴を共有する。四分木は、効率的空間検索に関して興味深く、パトリシアツリーはそれらの内部ノードの変動性に関して興味深い。
【0061】
実装によるＸＡＭＴｒｅｅは、隣接行列の２つの次元（行と列）にわたって扇形に広がるノードで構成される。各ノードは２ｎ×２ｎのセルで構成され、２軸にわたってｎビットを消費する。実装は、ＸＡＭＴｒｅｅ用のいくつかの種類の葉ノードと、挿入されたデータのボリュームに従って各種類を活用するツリーの最適化された構造とを提供する。したがって、実装は、スペース効率を犠牲にすることなく良好なクエリ時間を提供する。そのような最適化された挿入順序（すなわち、各種類の葉ノードが使用されるべきかによる順序）は、モートン順序（非特許文献１４参照）に従う。実装はまた、例えば非特許文献１５に記載されているように、リレーショナルクエリエンジンにおけるＡＶＸと呼ばれる新規のＣＰＵ命令を利用する。これはさらに、実装におけるクエリ経過時間を改善する。
【0062】
実装によるデータ構造は、それが書込みによって修正されるメモリ領域の数を制限し、（キャッシュミスを避けるために）キャッシュラインを尊重するように編成されている。さらに、ＸＡＭＴｒｅｅは最適化された挿入順序（すなわち、モートン符号化）を有し、その理想的に最適化された状態でＸＡＭＴｒｅｅを再構築することが簡単である。動的Ｋ２Ｔｒｅｅとは対照的に、ＸＡＭＴｒｅｅのアルゴリズムの複雑さは最悪のＯ（ｎ ｌｏｇｍ ｎ）でスペース使用の上限を有し、ここで、ｎは隣接行列に設定されたビットの数であり、挿入の順序は、動的Ｋ２と比べてＸＡＭＴｒｅｅにペナルティを与えない。基本的アクセス方法は、アルゴリズムの複雑さについて静的Ｋ２Ｔｒｅｅと同じ最悪ケースを有するが、隣接行列のトポロジーは、ＸＡＭＴｒｅｅがバランスのとれたツリーではないので、ＸＡＭＴｒｅｅデータ構造の性能をさらに改善する。さらに、ＸＡＭＴｒｅｅは、動的Ｋ２Ｔｒｅｅ（ＤＫ２）よりも隣接行列のトポロジーに対して敏感ではない。
【0063】
実装によれば、ＸＡＭＴＲｅｅは、四分木に類似したツリーと、座標ペアベクトルを格納する葉、およびビットマップを表す葉とを混合するデータ構造である。知られているように（例えば、非特許文献１０から）、四分木は、各内部ノードが正確に４つの子を有するツリーデータ構造である。四分木は、ほとんどの場合、２次元空間を４つの象限または領域に再帰的に細分化することによって分割するために使用される。葉セルに関連付けられたデータはアプリケーションによって異なるが、葉セルは「興味深い空間情報の単位」を表す。
【0064】
実装は、ＲＤＦグラフのデータを表すためにそれを使用する必要がある以下の関数に応答する隣接行列を実装する。
【0065】
「ｒ，ｃ」が、四分木で表される隣接行列の座標であるとき、ビットを設定することは、行列の対応するセルが「ｔｒｕｅ」（真）の値を有することを意味する（そして「ｆａｌｓｅ」（偽）の値をリセットする）：
・ ｓｅｔ（ｒ，ｃ） ｒ，ｃ座標におけるビットをｔｒｕｅに設定する
・ ｒｅｓｅｔ（ｒ，ｃ） ｒ，ｃ座標におけるビットをｆａｌｓｅにリセットする
・ ｔｅｓｔ（ｒ，ｃ）→Ｂｏｏｌｅａｎ ｒ，ｃ座標におけるビットの状態を返す
・ それ自体知られているように、任意の状態変化の通知を可能にするオブザーバ。そのようなオブザーバは、イテレータ（非特許文献１６参照）またはビジター（非特許文献１７参照）として実装され得る。オブザーバの例は以下の通りであり得る：
○ ｓｃａｎＲｏｗ（ｒ）→｛ｃ｝ これは、ｔｅｓｔ（ｒ，ｃ）がｔｒｕｅであるｃのセットを返す。ｓｃａｎＲｏｗは、ｒが不変であるｒ，ｃセットを返すこともある。
・ ｓｅｔ（ｒ，ｃ） ｒ，ｃ座標におけるビットをｔｒｕｅに設定する
・ ｒｅｓｅｔ（ｒ，ｃ） ｒ，ｃ座標におけるビットをｆａｌｓｅにリセットする
・ ｔｅｓｔ（ｒ，ｃ）→Ｂｏｏｌｅａｎ ｒ，ｃ座標におけるビットの状態を返す
・ それ自体知られているように、任意の状態変化の通知を可能にするオブザーバ。そのようなオブザーバは、イテレータ（非特許文献１６参照）またはビジター（非特許文献１７参照）として実装され得る。オブザーバの例は以下の通りであり得る：
○ ｓｃａｎＲｏｗ（ｒ）→｛ｃ｝ これは、ｔｅｓｔ（ｒ，ｃ）がｔｒｕｅであるｃのセットを返す。ｓｃａｎＲｏｗは、ｒが不変であるｒ，ｃセットを返すこともある。
【0066】
○ ｓｃａｎＣｏｌｕｍｎ（ｃ）→｛ｒ｝ これは、ｔｅｓｔ（ｒ，ｃ）がｔｒｕｅであるｒのセットを返す。ＳｃａｎＣｏｌｕｍｎは、ｃが不変であるｒ，ｃセットを返すこともある。
【0067】
○ ｓｃａｎＡｌｌ（）→｛ｒ，ｃ｝ これは、ｔｅｓｔ（ｒ，ｃ）がｔｒｕｅであるｒ，ｃのセットを返す。
【0068】
以下のアルゴリズムで使用されるビット演算
実装はさらに、以下の表１に列挙されるような符号なし整数に対するいくつかのビット演算を含む。
実装はさらに、以下の表１に列挙されるような符号なし整数に対するいくつかのビット演算を含む。
【0069】
【表1】
【0070】
ＸＡＭＴｒｅｅの要素の説明
ＸＡＭＴｒｅｅは、中間（すなわち、非終端）ノードと、ベクトル葉または座標のベクトルを有する葉と、ビットマップ葉またはビットマップを有する葉との３種類のノードから構成されるツリーデータ構造である。３つのノードの各々が以下に論じられる。
ＸＡＭＴｒｅｅは、中間（すなわち、非終端）ノードと、ベクトル葉または座標のベクトルを有する葉と、ビットマップ葉またはビットマップを有する葉との３種類のノードから構成されるツリーデータ構造である。３つのノードの各々が以下に論じられる。
【0071】
中間ノード（ＴＮ）
ＸＡＭＴｒｅｅの中間ノードＴＮは、任意選択のサブ要素を指すサイズ２ｎ×２ｎのインデックスの２次元配列からなる。この配列の各スロットは、サブアイテムを指定し得る。ｎは厳密に正の整数でなければならない。ＴＮは、サイズ２２ｎの１次元配列で表現され得、ここで、ＴＮに対する行および列は、（（行＊２ｎ）＋列）または（（列＊２ｎ）＋行）規則を使用して符号化され得る。実装は、１次元配列表現を利用し、（（行＊２ｎ）＋列）として表現を符号化する。
ＸＡＭＴｒｅｅの中間ノードＴＮは、任意選択のサブ要素を指すサイズ２ｎ×２ｎのインデックスの２次元配列からなる。この配列の各スロットは、サブアイテムを指定し得る。ｎは厳密に正の整数でなければならない。ＴＮは、サイズ２２ｎの１次元配列で表現され得、ここで、ＴＮに対する行および列は、（（行＊２ｎ）＋列）または（（列＊２ｎ）＋行）規則を使用して符号化され得る。実装は、１次元配列表現を利用し、（（行＊２ｎ）＋列）として表現を符号化する。
【0072】
以下では、ｎは定数であり、δと呼ばれる。さらに、実装は、２つの定数、すなわち、２δのショートカットとして（または同等にビット単位左シフト演算子１＜＜δとして）のＴＮＷＩＤＴＨと、ＴＮＷＩＤＴＨ２または２２δのショートカットとしてのＴＮＳＩＺＥとを使用する。
【0073】
実装は、δ＝２に設定する。そのような値は、ＸＡＭＴｒｅｅのノードを、現代のプロセッサのキャッシュラインサイズに容易に合わせられる比較的小さいサイズのノードとし、δ＝１についてｌｏｇ４ではなくｌｏｇ１６の複雑さを有するアルゴリズムをもたらすような、最適化された値である。変形例では、実装はδに他の値を設定することがある。
【0074】
実装は、ＴＮに３２ビットインデックスを設定して、６４バイト（５１２ビット＝２２×２２×３２）という限られたサイズのノードを有しながらも、数十億ビットの隣接行列を作成することができる。変形例では、実装は６４ビットインデックスを使用することがあるが、これはストレージの増大につながる。
【0075】
慣例的に、実装は、割り当てられていないノードを指定するためにインデックスを０に設定し、これにより、行列を分割するときに「ｔｒｕｅ」に評価されたセルを有する隣接行列のサブ要素がもはや存在しないことを示すことを意味する（例えば、既に引用された非特許文献３から当分野で知られている）。変形例では、実装は、割り当てられていないノードを指定するためのインデックス値として０以外の値を設定することがある。以下では、値（０または他の変形例のいずれか）はＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥと呼ばれる。
【0076】
座標ベクトルを有する葉（Ｖｎｎ）
ベクトル葉Ｖｎｎは、上述された中間ノードＴＮと正確に同じサイズを有するＸＡＭＴｒｅｅの要素である。実装は、ＸＡＭＴｒｅｅにおけるＶｎｎ葉の対応する要素の構造の先頭において特定の値の整数で各Ｖｎｎ葉を識別する。例えば、実装は、ＸＡＭＴｒｅｅにおける各Ｖｎｎ葉の対応する構造の先頭において値０ｘｆｆｆｆｆｆｆｆの３２ビット整数を有するＶｎｎ葉を識別するように設定することができる。変形例では、実装は、他の任意の値に設定することがある。以下では、任意のインデックス値はＶＥＣＴＯＲ＿ＬＥＡＦと呼ばれる。実装は、中間ノードＴＮについての無効なインデックスとして値ＶＥＣＴＯＲ＿ＬＥＡＦを設定することがある。
ベクトル葉Ｖｎｎは、上述された中間ノードＴＮと正確に同じサイズを有するＸＡＭＴｒｅｅの要素である。実装は、ＸＡＭＴｒｅｅにおけるＶｎｎ葉の対応する要素の構造の先頭において特定の値の整数で各Ｖｎｎ葉を識別する。例えば、実装は、ＸＡＭＴｒｅｅにおける各Ｖｎｎ葉の対応する構造の先頭において値０ｘｆｆｆｆｆｆｆｆの３２ビット整数を有するＶｎｎ葉を識別するように設定することができる。変形例では、実装は、他の任意の値に設定することがある。以下では、任意のインデックス値はＶＥＣＴＯＲ＿ＬＥＡＦと呼ばれる。実装は、中間ノードＴＮについての無効なインデックスとして値ＶＥＣＴＯＲ＿ＬＥＡＦを設定することがある。
【0077】
ベクトル葉は、ツリーノードに適合する固定最大容量隣接行列である。言い換えれば、Ｖｎｎ葉は、最大容量までｒ，ｃペアを格納し得る。実装は、Ｖｎｎノードに対して異なるレイアウト（すなわち、メモリレイアウト）を設定することができる。各レイアウトは、実装がＴＮに対して等しいまたは小さい（すなわち、ＴＮのサイズに適合できる）サイズのＶｎｎを必要とするという事実によって課されるサブタイプ間で共有される最大容量を有するベクトル葉のためのサブタイプを定義する。
【0078】
実装は、３つのサブタイプをＶ３２、Ｖ１６、およびＶ８として定義し、それぞれ３２ビット、１６ビット、または８ビットのインデックスサイズ（すべてのサブタイプの共有される最大サイズと組み合わせて、各サブタイプに格納されるｒ，ｃペアの最大容量に対応する）、および（使用中のスロット数に対応する）現在のサイズを有する。実装によれば、各サブタイプは、サブタイプに応じて、ベースペアｒ，ｃおよび／または可変長のベクトル（Ｖ３２、Ｖ１６、およびＶ８の各々について、それぞれ６４ビット、３２ビット、および１６ビット）を有することができる。長さは、データ構造内の使用される行－列座標の数を指す。長さは、Ｖ＜ｎｎ＞データ構造のタイプによって異なる。理論的には、長さは１とＶｎｎの最大長との間で変化する。言い換えれば、６４バイト葉ノードサイズの場合、実装に応じて、Ｖ３２では７まで、Ｖ１６では１３まで、Ｖ８では２４または２５までとなる。ベースペアｒ，ｃ（または明示的にｒｂａｓｅ，ｃｂａｓｅ）は、例えば、レイアウトにおけるオフセット値（例えば、ｒｏｆｆｓｅｔ，ｃｏｆｆｓｅｔ）と組み合わせて（例えば、ｒｂａｓｅ＋ｒｏｆｆｓｅｔ，ｃｂａｓｅ＋ｃｏｆｆｓｅｔを含む操作を使用して）、座標の各ペアを定義するために使用される。
【0079】
図６Ａは、いくつかのＶｎｎデータ構造のための方法の例に従って上述されたベクトルの長さを計算するための、Ｐｙｔｈｏｎ言語のサンプルコードを提示する。そのような例では、各葉ノードは、６４＊８ビットのサイズ（ｎｏｄｅ＿ｓｉｚｅ）であり、ヘッダが６４ビット（ｈｅａｄｅｒ＿ｓｉｚｅ）である。さらに、各中間ノードのサイズは３２ビット（ｉｎｄｅｘ＿ｂｉｔｓｉｚｅ）である。ｎ（またはデルタ）が２に設定され、ツリーの各レベルが２ビットを消費するので、偶数のビットサイズのみが報告される。
【0080】
図６Ｂは、異なるタイプ、すなわち、ｎｎの値によるＶｎｎタイプに対するＰｙｔｈｏｎコードの結果の表を提示する。「インデックス（index）」はＶｎｎにおけるｒおよびｃのインデックスビットサイズを意味し、「ベース（base）」はＶｎｎにおけるｒおよびｃの最小ベースビットサイズであり、「最大容量（max capacity）」はＶｎｎに格納され得るｒ，ｃペアの最大数である。
【0081】
図６Ａ～図６Ｂによれば、ベース値は、式ｉｎｄｅｘ＿ｂｉｔｓｉｚｅ－ｎによって計算され、最大容量は、式（（ｎｏｄｅ＿ｓｉｚｅ－ｈｅａｄｅｒ＿ｓｉｚｅ）－（２＊（ｉｎｄｅｘ＿ｂｉｔｓｉｚｅ－ｎ）））／／（２＊ｎ）によって計算される。図６Ｂに提示された結果は、さらに、異なるインデックスサイズの最大容量の間の比較が実現できることを示唆している。例えば、Ｖ６は、Ｖ８より３２％大きい最大容量を有し、良好な候補である。さらに、Ｖ１０およびＶ１２はそれぞれ、Ｖ１６よりも５４％および３０％大きい最大容量を有するが、Ｖ２４容量はＶ３２よりも２８％大きい。一方、Ｖ１６と比較したＶ１４、Ｖ２４と比較したＶ２０およびＶ２２、Ｖ２４およびＶ３２と比較したＶ２６は、より大きい容量という点で利益が小さい。さらに、Ｖ２４はＶ１６ノードを挿入するために必須の中間ノードの数を最小化するための興味深いフォーマットであり、Ｖ１２はＶ８ノードに関してであるが同じ理由で興味深い。
【0082】
上述されたタグの決定は、特に、少なくとも部分的に、図６Ａと同様の計算を含むことができる。
【0083】
実装は、ベクトル葉の深さによって、３２ビット、１６ビット、または８ビットのｒ，ｃの各々を使用することができる。言い換えれば、ＶＥＣＴＯＲ＿ＬＥＡＦがより深く作成されるほど、２つのｒ，ｃペアの間の差はより小さくなり、したがって、実装がこの値を表すために必要とするビット数がより少ない。一方、８ビット、１６ビット、および３２ビット基本演算を使用することにより、実装はデータの抽出を簡単かつ効率的に維持する。
【0084】
【0085】
図３Ａは、８バイトの８行の６４バイトデータ構造（Ｖ３２）のレイアウトを模倣した８×８表を提示する。実装は、図３Ａに提示されたレイアウトに７個までのｒ，ｃペアを格納することができ、各ｒ，ｃの抽出は、レイアウト内の格納された値を読み取ることによってなされる。
【0086】
図３Ｂは、図３Ａに提示されたＶ３２レイアウトの変形例を提示する。この変形によると、実装は、ｒ，ｃペアを符号化するために（後述される）符号化δ（ｒ，ｃ）を使用する。これらのｒ，ｃペアが順序付けられた場合、実装は、走査アルゴリズムをＫ２Ｔｒｅｅのように挙動するように維持し得る。
【0087】
図４は、Ｖ１６のメモリレイアウトの例を提示する。実装は、図４に提示されたレイアウトでは１３個までのｒ，ｃペアを格納することができる。実装は、ｒ，ｃのペア、ｒｎ＝Ｒｂａｓｅ＜＜１６｜Ｒｏｎおよびｃｎ＝Ｃｂａｓｅ＜＜１６｜Ｃｏｎを抽出し得る。このレイアウトによれば、ｒ，ｃペア値は、２１６×２１６サイズの変換された部分行列に制約される。言い換えれば、本方法は、ｒｎ＝（Ｒｂａｓｅ＊２１６）＋Ｒｏｎおよびｃｎ＝（Ｃｂａｓｅ＊２１６）＋Ｃｏｎｎとして、ペアｒ，ｃを計算してよく、ここで、ｘ＜＜ｎは、ｘ＊２ｎと等価である。最下位１６ビットはすべてゼロにされるので、ビット単位ＯＲ演算は加算によって置き換えられ得る。しかし、＜＜演算子（すなわち、ビット単位左シフト演算子）、および｜演算子（すなわち、ビット単位ＯＲ演算子）は、整数値にのみ適用できるので、それにより、正しい最適化のためにコンパイラをより良く導く。
【0088】
図５は、Ｖ８のメモリレイアウトの例を提示する。実装は、図５に提示されたレイアウトでは２４個までのｒ，ｃペアを格納することができる。実装は、ベース値とオフセットを加算することによってペアを抽出することができる。このレイアウトによれば、ｒ，ｃペア値は、２８×２８サイズの変換された部分行列内に制約される。
【0089】
実装の変形例では、上述された１つのＶＥＣＴＯＲ＿ＬＥＡＦタグの代わりに、ＶＥＣＴＯＲ＿ＬＥＡＶＥＳ範囲を使用し、Ｖ１６およびＶ８サブタイプ容量を増大させるために、この範囲のサブタイプおよびサイズを符号化することも可能である。
【0090】
ビットマップを有する葉（ＢＬ）
実装では、ツリー（すなわち、ＸＡＭＴｒｅｅ）で特定の深さを超えると、ツリーノードまたはベクトル葉のストレージコストは、データのビットマップ表現のコストよりも大きい。実装では、ＢＬだけが見つけられるＸＡＭＴｒｅｅ深さとしてＢＬＤＥＰＴＨ値を設定することがある。
実装では、ツリー（すなわち、ＸＡＭＴｒｅｅ）で特定の深さを超えると、ツリーノードまたはベクトル葉のストレージコストは、データのビットマップ表現のコストよりも大きい。実装では、ＢＬだけが見つけられるＸＡＭＴｒｅｅ深さとしてＢＬＤＥＰＴＨ値を設定することがある。
【0091】
例えば、δ＝２でインデックスが３２ビットのとき、ＴＮのコストは６４バイトであるが、ツリーの最後の２レベルは１６×１６ビットの部分行列を表す。それにより、ビットマップ葉を使用してストレージサイズを改善する。実装は、ツリーの最後の２レベルを表現するために、３２バイトに収まる２５６ビットのビットマップを使用し得る。ベクトル葉の代わりにＢＬを使用してこの部分行列に設定されたビットが数ビット未満である場合、実装はメモリコストを２分の１に削減し得るが、最後から３番目のベクトル（antepenultimate vector）（すなわち、ツリーの最後のレベルに対応するベクトル）が飽和された場合、実装は１６個までの葉を作成することがある。実装はビットマップ葉をＴＮおよびＶｎｎと同じ方法で割り当てないので、最後のＴＮのインデックスはビットマップ葉と同じものを指していない。特に、実装は、均質な方法でタグ付けなしでビットマップレイヤ（すなわち、ビットマップによって表現されるレイヤ）を割り当てる。実装は、膨大なメモリ使用を防止するセーフガードとしてビットマップ葉を活用している。
【0092】
実装は、δおよびインデックス幅の各場合について、ＴＮのツリーがビットマップのみを含む深さを識別する。例えば、δ＝２でインデックスの幅が３２ビットのとき、ツリーの各レベルはδビットを消費し、したがって、ＢＬＤＥＰＴＨ＝ｉｎｄｅｘｂｉｔｓ－２＊δは、３２－２－２＝２８ビットとなる。実装は、ＸＡＭＴｒｅｅの最後のレベルをビットマップとして表すことができる。あるいは、実装は、ビットマップがツリーノードより小さいので、δ＝１またはδ＝２についての２つの最後のレベルのビットマップを定義してもよい。δ＞２である変形例では、実装は、ＸＡＭＴｒｅｅの最後のレベルのビットマップ葉のみを定義し得る。
【0093】
ＸＡＭＴｒｅｅ構造
実装は、以下のような固定サイズ要素の２つの配列によってＸＡＭＴｒｅｅを構築することができる：
－ ＮＶと呼ばれるノードとベクトル葉の配列、および
－ ＢＭと呼ばれるビットマップ葉の配列。
実装は、以下のような固定サイズ要素の２つの配列によってＸＡＭＴｒｅｅを構築することができる：
－ ＮＶと呼ばれるノードとベクトル葉の配列、および
－ ＢＭと呼ばれるビットマップ葉の配列。
【0094】
実装は、メモリ（例えば、メモリヒープ）またはファイルのいずれかに２つの配列を作成し、格納することができる。ビットマップ要素のサイズがノードのサイズと同じである例では、実装はＢＭ配列を作成しなくてよい。実装は、ＢＭを使用して最適化を実行しない他の基準を考慮し得る。
【0095】
実装は、表２に要約された以下の関数を介して、ＮＶおよび／またはＢＭへのアクセスを管理することができる。
【0096】
【表2】
【0097】
以下に、ＢＭおよびＮＶにおける配列［ｉｎｄｅｘ］のｇｅｔおよびｓｅｔ操作の表記を提示する。実装は、ルートインデックスを含むヘッダ記述子を設定することができる。
【0098】
最初に、ＸＡＭＴｒｅｅの更新可能な（すなわち、動的な）バージョンが提示され、次に、読取り専用バージョンが詳細に示される。
【0099】
初期化
実装は、以下のステップに従って空のＸＡＭＴｒｅｅを作成することができる：
１．ＮＶ配列にスロットを割り当て、返されたインデックスをルートインデックスに格納する。
実装は、以下のステップに従って空のＸＡＭＴｒｅｅを作成することができる：
１．ＮＶ配列にスロットを割り当て、返されたインデックスをルートインデックスに格納する。
【0100】
２．ＮＶ［ｒｏｏｔ ｉｎｄｅｘ］を空のＶ３２に設定する。
【0101】
実装する関数
実装は、表３のような格納されたデータベースに対するＳＰＡＲＱＬクエリに応答するのに使用するために、以下の関数を備える。
実装は、表３のような格納されたデータベースに対するＳＰＡＲＱＬクエリに応答するのに使用するために、以下の関数を備える。
【0102】
【表3】
【0103】
実装はさらに、表４に列挙されるような以下の関数を実装する。
【0104】
【表4】
【0105】
次に、上記の関数の実装のアルゴリズムの詳細について論じられる。
【0106】
関数「Ｔｅｓｔ」のアルゴリズム
パラメータ：ｒ，ｃ チェックする行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ（深さ）＝０とする
アルゴリズム
１． カーソル（cursor）がＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、
ノードもいかなる種類の葉も存在せず、（ｒ，ｃ）に設定されたビットが存在しない
ｔｅｓｔはｆａｌｓｅを返さなければならない
２． そうではなく、ｄｅｐｔｈがＢＬＤＥＰＴＨである場合、有効なビットマップが存在する
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットをチェックする
ｔｅｓｔは、前のチェックの結果を返す
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］がＶＥＣＴＯＲ＿ＬＥＡＦである場合、座標ベクトル葉を取得する
ｔｅｓｔは、ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックする
ｔｅｓｔは、前のチェックの結果を返す
４． その他の場合、ツリーノードを取得し、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
カーソルをＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］に設定する
１から再開する
パラメータ：ｒ，ｃ チェックする行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ（深さ）＝０とする
アルゴリズム
１． カーソル（cursor）がＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、
ノードもいかなる種類の葉も存在せず、（ｒ，ｃ）に設定されたビットが存在しない
ｔｅｓｔはｆａｌｓｅを返さなければならない
２． そうではなく、ｄｅｐｔｈがＢＬＤＥＰＴＨである場合、有効なビットマップが存在する
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットをチェックする
ｔｅｓｔは、前のチェックの結果を返す
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］がＶＥＣＴＯＲ＿ＬＥＡＦである場合、座標ベクトル葉を取得する
ｔｅｓｔは、ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックする
ｔｅｓｔは、前のチェックの結果を返す
４． その他の場合、ツリーノードを取得し、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
カーソルをＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］に設定する
１から再開する
【0107】
関数「Ｓｅｔ」のアルゴリズム
パラメータ：ｒ，ｃ 設定する行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ＝０とする
アルゴリズム
１． ｃｕｒｓｏｒ＝ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、ノードもいかなる種類の葉も存在せず、この条件は無効である
２． そうではなく、ｄｅｐｔｈ＝ＢＬＤＥＰＴＨである場合、有効なビットマップが存在する
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットを設定する
戻る
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を取得する
ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックし、ｔｒｕｅが返った場合、
ＮＶ［ｃｕｒｓｏｒ］がｒ，ｃペアを挿入できないならば：
ａ． 現在の座標ベクトルを抽出する
ｂ． 現在の座標ベクトルサブタイプを、ｒ，ｃのペアを受け入れることができる別のサブタイプに変異させる。
ｃ． ｂが失敗した場合、現在の座標ベクトルをツリーノードに変異させ、コンテンツを２つ以上のサブ葉（ＶＬまたはＢＬのいずれか）に分配する
１つのサブ葉の場合、分配が失敗することがあり、より深いレベルでｃを繰り返し、これは、最終的に、すべての抽出された現在の座標ベクトルを受け入れることができる２つ以上のＶＬまたは１つもしくは複数のＢＬサブ葉への分割によって終了する
そうでない場合、ｒ，ｃペアを挿入する
パラメータ：ｒ，ｃ 設定する行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ＝０とする
アルゴリズム
１． ｃｕｒｓｏｒ＝ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、ノードもいかなる種類の葉も存在せず、この条件は無効である
２． そうではなく、ｄｅｐｔｈ＝ＢＬＤＥＰＴＨである場合、有効なビットマップが存在する
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットを設定する
戻る
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を取得する
ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックし、ｔｒｕｅが返った場合、
ＮＶ［ｃｕｒｓｏｒ］がｒ，ｃペアを挿入できないならば：
ａ． 現在の座標ベクトルを抽出する
ｂ． 現在の座標ベクトルサブタイプを、ｒ，ｃのペアを受け入れることができる別のサブタイプに変異させる。
ｃ． ｂが失敗した場合、現在の座標ベクトルをツリーノードに変異させ、コンテンツを２つ以上のサブ葉（ＶＬまたはＢＬのいずれか）に分配する
１つのサブ葉の場合、分配が失敗することがあり、より深いレベルでｃを繰り返し、これは、最終的に、すべての抽出された現在の座標ベクトルを受け入れることができる２つ以上のＶＬまたは１つもしくは複数のＢＬサブ葉への分割によって終了する
そうでない場合、ｒ，ｃペアを挿入する
【0108】
５． その他の場合、
ツリーノードが存在し、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
ＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］の次にする
次がＵＮＡＬＬＯＣＡＴＥＤノードである場合、
ｄｅｐｔｈ＝ＢＬＤＥＰＴＨであるならば、
ビットマップ葉をＢＭに割り当て、この値の次に設定する
そうでない場合、
座標ベクトル葉をＮＶに割り当て、この値の次に設定する
ＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］を次へ更新する
カーソルを次へ設定する
１から再開する
サブステップｂの変異は、ＸＡＭＴｒｅｅを非対称（すなわち、ツリー全体にわたって異なるサブタイプを有する）にするのものであり、Ｋ２－Ｔｒｅｅに見られるような退化を防止する。言い換えれば、局所性の問題（例えば、値が行列のある領域に散らばり、疎な行列の利点を妨げる）がある場合、この領域のノードだけがこの変異によって影響される（そして、Ｋ２Ｔｒｅｅのようにツリーのすべての類型論が影響されるわけではない）。
ツリーノードが存在し、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
ＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］の次にする
次がＵＮＡＬＬＯＣＡＴＥＤノードである場合、
ｄｅｐｔｈ＝ＢＬＤＥＰＴＨであるならば、
ビットマップ葉をＢＭに割り当て、この値の次に設定する
そうでない場合、
座標ベクトル葉をＮＶに割り当て、この値の次に設定する
ＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］を次へ更新する
カーソルを次へ設定する
１から再開する
サブステップｂの変異は、ＸＡＭＴｒｅｅを非対称（すなわち、ツリー全体にわたって異なるサブタイプを有する）にするのものであり、Ｋ２－Ｔｒｅｅに見られるような退化を防止する。言い換えれば、局所性の問題（例えば、値が行列のある領域に散らばり、疎な行列の利点を妨げる）がある場合、この領域のノードだけがこの変異によって影響される（そして、Ｋ２Ｔｒｅｅのようにツリーのすべての類型論が影響されるわけではない）。
【0109】
関数「Ｒｅｓｅｔ」のアルゴリズム
パラメータ：ｒ，ｃ リセットする行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ＝０とする
アルゴリズム
１． ｃｕｒｓｏｒ＝ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、
ノードもいかなる種類の葉も存在せず、削除するものもない。
パラメータ：ｒ，ｃ リセットする行および列
初期条件：
カーソルをルートインデックスとする
ＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）とする
ｄｅｐｔｈ＝０とする
アルゴリズム
１． ｃｕｒｓｏｒ＝ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥである場合、
ノードもいかなる種類の葉も存在せず、削除するものもない。
【0110】
戻る
２． そうではなく、ｄｅｐｔｈ＝ＢＬＤＥＰＴＨである場合、
有効なビットマップがある
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットをリセットする
戻る
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉が存在する
ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックし、ｆａｌｓｅが返った場合、
ＮＶ［ｃｕｒｓｏｒ］カーディナリティが１であるならば、以下が可能である：
ａ． ベクトル葉をクリアする
ｂ． カーソルがルートインデックスでない場合に、ノードを割当て解除し、親ノードを更新する
そうでない場合、ベクトル葉サブタイプに従って適切なアルゴリズムを使用して、ＮＶ［ｃｕｒｓｏｒ］からｒ，ｃペアを削除する
戻る
２． そうではなく、ｄｅｐｔｈ＝ＢＬＤＥＰＴＨである場合、
有効なビットマップがある
ＢＭにおけるカーソルでのビットマップの（ｒ，ｃ）におけるビットをリセットする
戻る
３． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉が存在する
ベクトル葉サブタイプに従って適切なアルゴリズムを使用してｒ，ｃペアの存在をチェックし、ｆａｌｓｅが返った場合、
ＮＶ［ｃｕｒｓｏｒ］カーディナリティが１であるならば、以下が可能である：
ａ． ベクトル葉をクリアする
ｂ． カーソルがルートインデックスでない場合に、ノードを割当て解除し、親ノードを更新する
そうでない場合、ベクトル葉サブタイプに従って適切なアルゴリズムを使用して、ＮＶ［ｃｕｒｓｏｒ］からｒ，ｃペアを削除する
戻る
【0111】
６． その他の場合、
ツリーノードを有しており、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
カーソルをＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］に設定する
１から再開する
ＳｃａｎＡｌｌ、ＳｃａｎＲｏｗ、およびＳｃａｎＣｏｌｕｍｎの一般性
ここで、ｓｃａｎＡｌｌ、ｓｃａｎＲｏｗ、およびｓｃａｎＣｏｌｕｍｎの非回帰アルゴリズムについて論じられる。これらのアルゴリズムは、固定サイズのスタックを使用する。
ツリーノードを有しており、ツリーを下に移動する
ｄｅｐｔｈをｄｅｐｔｈ＋２に設定する
ＲＣ＝ｒｏｌ（ＲＣ，２δ）とする
ｃｅｌｌ＝ｍａｓｋ（ＲＣ，２δ）とする
カーソルをＮＶ［ｃｕｒｓｏｒ］［ｃｅｌｌ］に設定する
１から再開する
ＳｃａｎＡｌｌ、ＳｃａｎＲｏｗ、およびＳｃａｎＣｏｌｕｍｎの一般性
ここで、ｓｃａｎＡｌｌ、ｓｃａｎＲｏｗ、およびｓｃａｎＣｏｌｕｍｎの非回帰アルゴリズムについて論じられる。これらのアルゴリズムは、固定サイズのスタックを使用する。
【0112】
これらのアルゴリズムは、効率的なスキャンアルゴリズムであり、なぜならば、ビジターバージョン（非特許文献１７参照）がヒープ割当て（非特許文献２０参照）を必要とせず、抽象反復子（非特許文献２１参照）が１回のヒープ割当てだけで様々な言語で実装されることが可能であり、具体反復子がヒープ割当てなしで実装されることが可能であるからである。したがって、実装は、ヒープ割当てを改善するために再帰アルゴリズムの代わりにビジターまたは反復子パターンを使用し得る。当分野で知られているように、プログラミング言語に組み込まれたジェネレータ概念がある限り、すべての提示された反復子アルゴリズムが再帰的に表現され得るという事実にかかわらず、プログラミング言語によって提供される何らかの手段なしに、再帰アルゴリズムから反復子を記述することはむしろ困難である。一方で、再帰ビジター、すなわち反復子から実装されたビジターを得ることは自明であるが、ジェネレータ概念なしの再帰反復子の取得は複雑である。実装では、スタックオブジェクトのサイズは固定されているので、動的割当てなしでそれを割り当てることができる。これは、少なくとも１つの割当てを有する抽象反復子の実装を改善する。さらに、このアルゴリズムの再帰バージョンを得ることは常に可能である。
【0113】
関数「ＳｃａｎＡｌｌ」のアルゴリズム
実装によれば、このアルゴリズムは、内部ノードＴＮの幅優先走査を使用して、ＸＡＭＴｒｅｅのすべての葉にわたって反復される。
実装によれば、このアルゴリズムは、内部ノードＴＮの幅優先走査を使用して、ＸＡＭＴｒｅｅのすべての葉にわたって反復される。
【0114】
以下のデータおよび操作を有するＳｃａｎＣｏｎｔｅｘｔのスタックを定義する：
データ構造：
ＳｃａｎＣｏｎｔｅｘｔはレコードであり、これは、現在のノードに「ｃｕｒｒｅｎｔ＿ｎｏｄｅ」インデックスおよび「ｐｏｓｉｔｉｏｎ」を含む。「ｃｕｒｒｅｎｔ＿ｎｏｄｅ」は、スキャンされるＮＶ配列またはＢＭ配列におけるノードまたは葉のインデックスである。「ｐｏｓｉｔｉｏｎ」インデックスは、ｃｕｒｒｅｎｔ＿ｎｏｄｅがツリーノードである場合に処理する位置を示す。「ｐｏｓｉｔｉｏｎ」のインデックスは、整数もしくは整数のペアであり、または（後述される）ｂａｓｅＲＣから導出され得る。ＳｃａｎＣｏｎｔｅｘｔレコードは、ＮＶ［ｃｕｒｒｅｎｔ＿ｎｏｄｅ］へのポインタのような他の何らかのキャッシュデータを保持することもあり、この場合、ｃｕｒｒｅｎｔ＿ｎｏｄｅは最適化され得る。Ｓｔａｃｋはレコードであり、これは以下を含む：
１． ＳｃａｎＣｏｎｔｅｘｔの＿ｄａｔａ固定サイズ配列。配列サイズは、ＢＬＤＥＰＴＨ／δよりも大きくなければならない。実装は、レコードの配列であってよく、また、いくつかの配列、例えば、＿ｄａｔａ＿ｃｕｒｒｅｎｔ＿ｎｏｄｅ配列および＿ｄａｔａ＿ｐｏｓｉｔｉｏｎ配列を使用することもできる。
データ構造：
ＳｃａｎＣｏｎｔｅｘｔはレコードであり、これは、現在のノードに「ｃｕｒｒｅｎｔ＿ｎｏｄｅ」インデックスおよび「ｐｏｓｉｔｉｏｎ」を含む。「ｃｕｒｒｅｎｔ＿ｎｏｄｅ」は、スキャンされるＮＶ配列またはＢＭ配列におけるノードまたは葉のインデックスである。「ｐｏｓｉｔｉｏｎ」インデックスは、ｃｕｒｒｅｎｔ＿ｎｏｄｅがツリーノードである場合に処理する位置を示す。「ｐｏｓｉｔｉｏｎ」のインデックスは、整数もしくは整数のペアであり、または（後述される）ｂａｓｅＲＣから導出され得る。ＳｃａｎＣｏｎｔｅｘｔレコードは、ＮＶ［ｃｕｒｒｅｎｔ＿ｎｏｄｅ］へのポインタのような他の何らかのキャッシュデータを保持することもあり、この場合、ｃｕｒｒｅｎｔ＿ｎｏｄｅは最適化され得る。Ｓｔａｃｋはレコードであり、これは以下を含む：
１． ＳｃａｎＣｏｎｔｅｘｔの＿ｄａｔａ固定サイズ配列。配列サイズは、ＢＬＤＥＰＴＨ／δよりも大きくなければならない。実装は、レコードの配列であってよく、また、いくつかの配列、例えば、＿ｄａｔａ＿ｃｕｒｒｅｎｔ＿ｎｏｄｅ配列および＿ｄａｔａ＿ｐｏｓｉｔｉｏｎ配列を使用することもできる。
【0115】
２． スタックにおける位置を示す＿ｔｏｐ整数。このフィールドは０に初期化され、プッシュ時にインクリメントされ、ポップ時にデクリメントされる。同じ特徴を実行するためにポインタが使用され得る。＿ｔｏｐがヌルの場合、スタックは空である。
【0116】
３． スキャン中に更新されるｂａｓｅＲＣ座標。δは２のべき乗であるので、ｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎはモートン符号化または部分ノートン符号化を使用して符号化されることが可能であり、これはこれら２つのデータを管理するための操作の数を最小限にするために有用であり得る。ｂａｓｅＲＣは、本発明を変更することなく、２つの整数ｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎに置き換えられることが可能である。ｂａｓｅＲｏｗ（ｂａｓｅＣｏｌｕｍそれぞれ）は、ｄｅｃｏｄｅＲｏｗδ（ｂａｓｅＲＣ）（ｄｅｃｏｄｅＣｏｌδ（ｂａｓｅＲＣ）それぞれ）を計算することによって取り出され得る。
【0117】
スタック操作は：
１． ＿ｔｏｐが０の場合、空がｔｒｕｅである
２． ｐｏｐは：
ａ． ＿ｔｏｐを１デクリメントすることによってｓｔａｃｋの先頭をドロップする
ｂ． ｂａｓｅＲＣペアを調整する
ｂａｓｅＲＣ＞＞＞（２δ）の結果にｂａｓｅＲＣを設定する
３． ｔｏｐが＿ｄａｔａ［＿ｔｏｐ－１］を返す
４． ｉｓ ＢＬＤｅｐｔｈが＿ｔｏｐ＝＝ＢＬＤＥＰＴＨ／δを返す
５． ｐｕｓｈ（ｉｎｔｅｇｅｒ ｃｅｌｌ）
ａ． ＿ｔｏｐを１インクリメントする
ｂ． ｂａｓｅＲＣをＣｏｐｙＬｏｗｅｓｔｓＢｉｔｓ（ｂａｓｅＲＣ，ｃｅｌｌ，２δ）＜＜（２δ）の結果に設定する
１． ＿ｔｏｐが０の場合、空がｔｒｕｅである
２． ｐｏｐは：
ａ． ＿ｔｏｐを１デクリメントすることによってｓｔａｃｋの先頭をドロップする
ｂ． ｂａｓｅＲＣペアを調整する
ｂａｓｅＲＣ＞＞＞（２δ）の結果にｂａｓｅＲＣを設定する
３． ｔｏｐが＿ｄａｔａ［＿ｔｏｐ－１］を返す
４． ｉｓ ＢＬＤｅｐｔｈが＿ｔｏｐ＝＝ＢＬＤＥＰＴＨ／δを返す
５． ｐｕｓｈ（ｉｎｔｅｇｅｒ ｃｅｌｌ）
ａ． ＿ｔｏｐを１インクリメントする
ｂ． ｂａｓｅＲＣをＣｏｐｙＬｏｗｅｓｔｓＢｉｔｓ（ｂａｓｅＲＣ，ｃｅｌｌ，２δ）＜＜（２δ）の結果に設定する
【0118】
６． ｎｅｘｔＡｌｌ
ａ． ｃｕｒをｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅとする
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ＮＶ［ｃｕｒ］において、セルから開始する次のＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥをスキップし、相応にセルを更新する
中断するまで繰り返す
ｉ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． ｃｅｌｌを１インクリメントする
ｄ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
ｐｏｐ（）
ｅ． そうでない場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋１に更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈ（ｃｅｌｌ）
ｉｖ． ｔｏｐ．ｐｏｓｉｔｉｏｎを０に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
ａ． ｃｕｒをｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅとする
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ＮＶ［ｃｕｒ］において、セルから開始する次のＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥをスキップし、相応にセルを更新する
中断するまで繰り返す
ｉ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． ｃｅｌｌを１インクリメントする
ｄ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
ｐｏｐ（）
ｅ． そうでない場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋１に更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈ（ｃｅｌｌ）
ｉｖ． ｔｏｐ．ｐｏｓｉｔｉｏｎを０に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
【0119】
ＳｃａｎＡｌｌアルゴリズム
１． ｓｔａｃｋを作成する
２． ルートインデックスをｓｔａｃｋにプッシュする
ａ． ｐｕｓｈ（０）
ｂ． ｓｔａｃｋ．ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
ｃ． ｔｏｐ．ｐｏｓｉｔｉｏｎを０に更新する
１． ｓｔａｃｋを作成する
２． ルートインデックスをｓｔａｃｋにプッシュする
ａ． ｐｕｓｈ（０）
ｂ． ｓｔａｃｋ．ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
ｃ． ｔｏｐ．ｐｏｓｉｔｉｏｎを０に更新する
【0120】
３． ｓｔａｃｋが空でない間に、
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
ｉ． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）
ｉｉ． ｐｏｐ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＡｌｌを呼び出すことによって次のスタック状態を計算する
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
ｉ． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）
ｉｉ． ｐｏｐ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＡｌｌを呼び出すことによって次のスタック状態を計算する
【0121】
関数「ＳｃａｎＲｏｗ」のアルゴリズム
このアルゴリズムでは、入力パラメータはスキャンする行ｒであり、内部ノードＴＮの幅優先走査（非特許文献２２）を使用してＸＡＭＴｒｅｅのすべての葉にわたってアルゴリズムが繰り返される。このアルゴリズムは、上述されたＳｃａｎＡｌｌの改良版である。
このアルゴリズムでは、入力パラメータはスキャンする行ｒであり、内部ノードＴＮの幅優先走査（非特許文献２２）を使用してＸＡＭＴｒｅｅのすべての葉にわたってアルゴリズムが繰り返される。このアルゴリズムは、上述されたＳｃａｎＡｌｌの改良版である。
【0122】
データ構造：
実装は、ｓｃａｎＡｌｌで使用されるスタックと同様のスタックを使用し、＿ｆｉｌｔｅｒＲＣフィールドをスタックに関連付ける。＿ｆｉｌｔｅｒＲＣは、ＰａｒｔｉａｌＥｎｃｏｄｅ（ｒ，δ）＜＜δによって初期化される。具体的には、＿ｆｉｌｔｅｒＲＣが最初にＥｎｃｏｄｅδ（ｒ，０）に設定され、次いで、ＸＡＭＴｒｅｅスキャン中に、実装は、ノード（ＴＮ）のスキャン開始時に２δだけ左に論理回転（ＲＯＬ）を実行し、ノードのスキャン終了時に２δだけ右に論理回転（ＲＯＲ）を実行する。それ自体知られているように、ビット単位演算ＲＯＬ（ｎ）は、ビットのソース配列（Ｓｏｕｒｃｅ）をビットの宛先配列（Ｄｅｓｔ）に変換するために、以下のビット単位演算を実行する：
Ｉについて０からｗ－１まで繰り返す間、
Ｄｅｓｔ（ｉ＋ｎ）％ｗ＝Ｓｏｕｒｃｅ（ｉ）
ここで、ｗは、ソース配列のビット数であり、これは宛先配列のビット数にも等しい。それにより、この一連のビット単位演算によって、配列の上位２δビットが配列の下位２δビットとなる。結果として、下位２δビットをマスクすることで、すなわち、＿ｆｉｌｔｅｒＲＣ ２δの適用によって、配列の最下位ビットが、使用する初期位置を含む。これは、実装が、スキャンするＴＮの開始インデックスを取得するのに役立つ。
実装は、ｓｃａｎＡｌｌで使用されるスタックと同様のスタックを使用し、＿ｆｉｌｔｅｒＲＣフィールドをスタックに関連付ける。＿ｆｉｌｔｅｒＲＣは、ＰａｒｔｉａｌＥｎｃｏｄｅ（ｒ，δ）＜＜δによって初期化される。具体的には、＿ｆｉｌｔｅｒＲＣが最初にＥｎｃｏｄｅδ（ｒ，０）に設定され、次いで、ＸＡＭＴｒｅｅスキャン中に、実装は、ノード（ＴＮ）のスキャン開始時に２δだけ左に論理回転（ＲＯＬ）を実行し、ノードのスキャン終了時に２δだけ右に論理回転（ＲＯＲ）を実行する。それ自体知られているように、ビット単位演算ＲＯＬ（ｎ）は、ビットのソース配列（Ｓｏｕｒｃｅ）をビットの宛先配列（Ｄｅｓｔ）に変換するために、以下のビット単位演算を実行する：
Ｉについて０からｗ－１まで繰り返す間、
Ｄｅｓｔ（ｉ＋ｎ）％ｗ＝Ｓｏｕｒｃｅ（ｉ）
ここで、ｗは、ソース配列のビット数であり、これは宛先配列のビット数にも等しい。それにより、この一連のビット単位演算によって、配列の上位２δビットが配列の下位２δビットとなる。結果として、下位２δビットをマスクすることで、すなわち、＿ｆｉｌｔｅｒＲＣ ２δの適用によって、配列の最下位ビットが、使用する初期位置を含む。これは、実装が、スキャンするＴＮの開始インデックスを取得するのに役立つ。
【0123】
実装は、ＳｃａｎＡｌｌで説明されたＳｔａｃｋを以下の操作で拡張する：
１． ｉｎｉｔＦｉｌｔｅｒ（ｒ，ｃ）
ａ． ＿ｆｉｌｔｅｒＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）に設定する
ｂ． ｐｕｓｈＦｉｌｔｅｒ（０）
ｃ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
ｄ． ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に更新する
１． ｉｎｉｔＦｉｌｔｅｒ（ｒ，ｃ）
ａ． ＿ｆｉｌｔｅｒＲＣ＝Ｅｎｃｏｄｅδ（ｒ，ｃ）に設定する
ｂ． ｐｕｓｈＦｉｌｔｅｒ（０）
ｃ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
ｄ． ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に更新する
【0124】
２． ｐｏｐＦｉｌｔｅｒは：
ａ． ｐｏｐを呼び出す
ｂ． ＿ｆｉｌｔｅｒＲＣをｒｏｒ（＿ｆｉｌｔｅｒＲＣ２δ）に設定する
３． ｐｕｓｈＦｉｌｔｅｒ（ｉｎｔｅｇｅｒ ｃｅｌｌ）
ａ． ｐｕｓｈ（ｃｅｌｌ）を呼び出す
ｂ． ＿ｆｉｌｔｅｒＲＣをｒｏｌ（＿ｆｉｌｔｅｒＲＣ２δ）に設定する
ａ． ｐｏｐを呼び出す
ｂ． ＿ｆｉｌｔｅｒＲＣをｒｏｒ（＿ｆｉｌｔｅｒＲＣ２δ）に設定する
３． ｐｕｓｈＦｉｌｔｅｒ（ｉｎｔｅｇｅｒ ｃｅｌｌ）
ａ． ｐｕｓｈ（ｃｅｌｌ）を呼び出す
ｂ． ＿ｆｉｌｔｅｒＲＣをｒｏｌ（＿ｆｉｌｔｅｒＲＣ２δ）に設定する
【0125】
４． ｎｅｘｔＲｏｗ
ＴＮのすべてのセルをスキャンする代わりに、ｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）から、除外されたｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）＋ＴＮＷＩＤＴＨまで、１行のみをスキャンする
ＴＮのすべてのセルをスキャンする代わりに、ｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）から、除外されたｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）＋ＴＮＷＩＤＴＨまで、１行のみをスキャンする
【0126】
ａ． ｃｕｒをｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅとする
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ｅｎｄをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）＋ＴＮＷＩＤＴＨとするが、セル（ｃｅｌｌ ｜（ＴＮＷＩＤＴＨ－１））＋１から導出されることも可能である（実装は＿ｆｉｌｔｅｒＲＣをロードする必要のない後者の形式を好む）。
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ｅｎｄをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）＋ＴＮＷＩＤＴＨとするが、セル（ｃｅｌｌ ｜（ＴＮＷＩＤＴＨ－１））＋１から導出されることも可能である（実装は＿ｆｉｌｔｅｒＲＣをロードする必要のない後者の形式を好む）。
【0127】
ｄ． ＮＶ［ｃｕｒ］において、セルから開始する次のＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥをスキップし、以下のステップに従ってセルを更新する：
中断まで繰り返す
ｉ． ｃｅｌｌ＞＝ｅｎｄである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． セルを１インクリメントする
ｅ． ｃｅｌｌ＞＝ｅｎｄである場合、
ｐｏｐＦｉｌｔｅｒ（）
ｆ． その他の場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋１に更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈＦｉｌｔｅｒ（ｃｅｌｌ）
ｉｖ．ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
中断まで繰り返す
ｉ． ｃｅｌｌ＞＝ｅｎｄである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． セルを１インクリメントする
ｅ． ｃｅｌｌ＞＝ｅｎｄである場合、
ｐｏｐＦｉｌｔｅｒ（）
ｆ． その他の場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋１に更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈＦｉｌｔｅｒ（ｃｅｌｌ）
ｉｖ．ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
【0128】
ＳｃａｎＲｏｗアルゴリズム
１． ｓｔａｃｋを作成する
２． フィルタを初期化する
ａ． ｓｔａｃｋ ｉｎｉｔＦｉｌｔｅｒ（ｒ，０）
ｂ． ｓｔａｃｋ．ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
３． ｓｔａｃｋが空でない間に、
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
ｉ． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎ、および入力パラメータｒによるフィルタを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）、ならびに入力パラメータｒによるフィルタから、すべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＲｏｗを呼び出すことによって次のスタック状態を計算する
１． ｓｔａｃｋを作成する
２． フィルタを初期化する
ａ． ｓｔａｃｋ ｉｎｉｔＦｉｌｔｅｒ（ｒ，０）
ｂ． ｓｔａｃｋ．ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをルートインデックスに更新する
３． ｓｔａｃｋが空でない間に、
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
ｉ． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎ、および入力パラメータｒによるフィルタを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）、ならびに入力パラメータｒによるフィルタから、すべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＲｏｗを呼び出すことによって次のスタック状態を計算する
【0129】
関数「ＳｃａｎＣｏｌｕｍｎ」のアルゴリズム
このアルゴリズムでは、入力パラメータはスキャンする行ｃであり、内部ノードＴＮの幅優先走査を使用してＸＡＭＴｒｅｅのすべての葉にわたってアルゴリズムが繰り返される。このアルゴリズムは、上述されたｓｃａｎＣｏｌｕｍｎｓｃａｎＲｏｗの改良版である。
このアルゴリズムでは、入力パラメータはスキャンする行ｃであり、内部ノードＴＮの幅優先走査を使用してＸＡＭＴｒｅｅのすべての葉にわたってアルゴリズムが繰り返される。このアルゴリズムは、上述されたｓｃａｎＣｏｌｕｍｎｓｃａｎＲｏｗの改良版である。
【0130】
データ構造：
実装は、上述されたｓｃａｎＲｏｗで使用されたのと同じスタックを使用する。しかし、＿ｆｉｌｔｅｒＲＣは、ＰａｒｔｉａｌＥｎｃｏｄｅ（Ｅｎｃｏｄｅδ（０，ｃ，δ）によって初期化される。実装は、ＳｃａｎＲｏｗで説明されたＳｔａｃｋを以下の操作で拡張する：
１． ｎｅｘＣｏｌｕｍｎ
ＴＮのすべてのセルをスキャンする代わりに、ｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）から、ＴＮＷＩＤＴＨステップによって除外されたＴＮＳＩＺＥまで、１列のみをスキャンする
ａ． ｃｕｒをｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅとする
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ＮＶ［ｃｕｒ］において、セルから開始する次のＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥをスキップし、以下に従ってセルを更新する：
中断まで繰り返す
ｉ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． セルをＴＮＷＩＤＴＨでインクリメントする
ｄ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
ｐｏｐＦｉｌｔｅｒ（）
ｅ． その他の場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋ＴＮＷＩＤＴＨに更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈＦｉｌｔｅｒ（ｃｅｌｌ）
ｉｖ． ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
ＳｃａｎＣｏｌｕｍｎアルゴリズム
１． ｓｔａｃｋを作成する
２． フィルタを初期化する
ａ． ｓｔａｃｋ ｉｎｉｔＦｉｌｔｅｒ（０，ｃ）
実装は、上述されたｓｃａｎＲｏｗで使用されたのと同じスタックを使用する。しかし、＿ｆｉｌｔｅｒＲＣは、ＰａｒｔｉａｌＥｎｃｏｄｅ（Ｅｎｃｏｄｅδ（０，ｃ，δ）によって初期化される。実装は、ＳｃａｎＲｏｗで説明されたＳｔａｃｋを以下の操作で拡張する：
１． ｎｅｘＣｏｌｕｍｎ
ＴＮのすべてのセルをスキャンする代わりに、ｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）から、ＴＮＷＩＤＴＨステップによって除外されたＴＮＳＩＺＥまで、１列のみをスキャンする
ａ． ｃｕｒをｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅとする
ｂ． ｃｅｌｌをｔｏｐ．ｐｏｓｉｔｉｏｎとする
ｃ． ＮＶ［ｃｕｒ］において、セルから開始する次のＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥをスキップし、以下に従ってセルを更新する：
中断まで繰り返す
ｉ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
中断する
ｉｉ． ＵＮＡＬＬＯＣＡＴＥＤ＿ＮＯＤＥ！＝ＮＶ［ｃｕｒ］［ｃｅｌｌ］である場合、
中断する
ｉｉｉ． セルをＴＮＷＩＤＴＨでインクリメントする
ｄ． ｃｅｌｌ＞＝ＴＮＳＩＺＥである場合、
ｐｏｐＦｉｌｔｅｒ（）
ｅ． その他の場合、
ｉ． ｄｏｗｎ ｉｎｄｅｘをＮＶ［ｃｕｒ］［ｃｅｌｌ］とする
ｉｉ． コールごとにｔｏｐ．ｐｏｓｉｔｉｏｎをｃｅｌｌ＋ＴＮＷＩＤＴＨに更新する
ｉｉｉ． ｐｏｓｉｔｉｏｎをプッシュおよび更新することによってｓｔａｃｋを更新する
ｐｕｓｈＦｉｌｔｅｒ（ｃｅｌｌ）
ｉｖ． ｔｏｐ．ｐｏｓｉｔｉｏｎをｍａｓｋ（＿ｆｉｌｔｅｒＲＣ，２δ）に設定する
ｖ． ｔｏｐ．ｃｕｒｒｅｎｔ＿ｎｏｄｅをｄｏｗｎ ｉｎｄｅｘに更新する
ＳｃａｎＣｏｌｕｍｎアルゴリズム
１． ｓｔａｃｋを作成する
２． フィルタを初期化する
ａ． ｓｔａｃｋ ｉｎｉｔＦｉｌｔｅｒ（０，ｃ）
【0131】
４． ｓｔａｃｋが空でない間に、
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
１． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎ、および入力パラメータｃによるフィルタを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）、および入力パラメータｃによるフィルタから、すべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＣｏｌｕｍｎを呼び出すことによって次のスタック状態を計算する
読取り専用バージョン
実装はまた、更新可能（すなわち動的）バージョンと若干異なる読取り専用バージョンを含んでよい。
ａ． ｓｔａｃｋがＢＬＤｅｐｔｈである場合、
ビットマップ葉を有する
１． スタックｂａｓｅＲｏｗ、ｂａｓｅＣｏｌｕｍｎ、および入力パラメータｃによるフィルタを使用して、ＢＭ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］からすべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｂ． そうではなく、ＮＶ［ｃｕｒｓｏｒ］［０］＝ＶＥＣＴＯＲ＿ＬＥＡＦである場合、
座標ベクトル葉を有する
ｉ． ＮＶ［ｓｔａｃｋ ｔｏｐ ｃｕｒｒｅｎｔ＿ｎｏｄｅ］（スタックｂａｓｅＲｏｗおよびｂａｓｅＣｏｌｕｍｎを使用してよい）、および入力パラメータｃによるフィルタから、すべての座標を得る
ｉｉ． ｐｏｐＦｉｌｔｅｒ ｓｔａｃｋ
ｃ． その他の場合、
ツリーノードを有する
ｉ． ｎｅｘｔＣｏｌｕｍｎを呼び出すことによって次のスタック状態を計算する
読取り専用バージョン
実装はまた、更新可能（すなわち動的）バージョンと若干異なる読取り専用バージョンを含んでよい。
【0132】
読取り専用バージョンでは、データ構造は更新される必要はない（すなわち、設定およびリセット操作が利用可能ではない）。さらに、実装は、既存の隣接行列をスキャンすることによって、またはＸＡＭＴｒｅｅから、グラフデータベースの読取り専用バージョンを格納する（すなわち、作成する）ことができる。実装の読取り専用バージョンは、ストレージのためのメモリ使用量をさらに最適化する。
【0133】
ＸＡＭＴｒｅｅの読取り専用バージョンは、ＲＯＸＡＭＴｒｅｅ（読取り専用ＸＡＭＴｒｅｅ）と呼ばれる。
【0134】
読取り専用メモリレイアウト
動的バージョンにおけるツリーノードの固定サイズ、すなわち、定義された２２δインデックススロット（すなわちＴＮ）は、すべて使用されることがほとんどない。通常、ＴＮは疎である。インデックススロットが一杯になるのを回避することは、更新可能なデータ構造にとって、新しいノードや葉が作成されるべきときにＯ（１）更新を維持するために重要である。
動的バージョンにおけるツリーノードの固定サイズ、すなわち、定義された２２δインデックススロット（すなわちＴＮ）は、すべて使用されることがほとんどない。通常、ＴＮは疎である。インデックススロットが一杯になるのを回避することは、更新可能なデータ構造にとって、新しいノードや葉が作成されるべきときにＯ（１）更新を維持するために重要である。
【0135】
本方法の実装は、使用されるインデックスを表すビットマスク（ビットマスクについては非特許文献２３を参照されたい）を使用することにより、インデックスのセットをパックしＴＮのスパース性を維持することを回避する、読取り専用の実装を有することができる。以下では、このビットマスクはｍｎと呼ばれる。δ＝２を有する所与のＸＡＭＴｒｅｅの場合、このマスクを格納するには１６ビット整数で十分である。例えば、３２ビット整数のツリーノードは、３つのセル（例えば、位置４、７、および８に配置されたセル）を使用することができる。それにより、実装は、情報を保持するために、６４バイト（４＊１６）の代わりに１４バイト（すなわち、２＋３＊４）のみを必要とする。同様に、１６ビットビットマスクは、インデックス４、７、および８が使用され、０ｂ００００’０００１’１００１’００００（２４＋２７＋２８）を含み得る。セルに関連付けられたインデックスの位置は、テストされたセルまでのポピュレーションカウント（すなわち、ｐｏｐｃｏｕｎｔ（ｍｎ＆（２ｃｅｌｌ－１））を使用して計算されることが可能であり、このとき、インデックス４、７、および８に対して、それぞれ０、１、および２を返す。
【0136】
しかし、メモリ空間をより良く使用するようにすることは可能である。ＸＡＭＴｒｅｅと同様に、ＲＯＸＡＭｔｒｅｅは、２つのファミリーのサブ要素のツリーノードおよび葉を有する。例えば、ＢＬＤＥＰＴＨでは、実装はビットマップ葉を他のタイプの葉に置き換えることがない。結果として、実装では、インデックスが省略でき、ビットマップ葉は直接ｍｎの後に配置される。
【0137】
ＢＬＤＥＰＴＨツリーノード以外のレベルでは、ベクトル葉とツリーノードを混合することが頻繁であり、この葉を指すインデックスを保持する必要を回避するために、実装は、（ｍｌと呼ばれる）第２のビットマスクを使用してよい。第２のビットマスクの使用は、すべてのベクトル葉のインデックスを格納するのを回避するのに役立つ。先の例では、ツリーノードがインデックス４、７、および８のセルを使用する場合、７はベクトル葉である。ｍｌビットマスクは０ｂ００００’００００’１０００’００００（２７）を含み、マスクおよび（もしあれば）ＴＮインデックスのすぐ後に座標ベクトルがあることを示している。実装では、ｍｎビットマスクはすべてのサブ要素マスクを含み、ｍｌマスクは葉を含む。ｍｎとｍｌの排他的論理和を実行することによって、ツリーノードビットマスクを得ることは簡単である。
【0138】
読取り専用バージョンでは、実装がベクトルノードを単純化することもできる。ＸＡＭＴｒｅｅに関して上述されたメモリレイアウト（例えば、Ｖ３２、Ｖ１６、Ｖ８）の主な制約の１つは、簡単に更新可能であり、ツリーノードサイズに適合されるように、それらを単純に維持することである。
【0139】
読取り専用データ構造の場合、実装は、（例えば、参照により本明細書に組み込まれる、Ｄａｓｓａｕｌｔ Ｓｙｓｔｅｍｅｓによる特許文献１に開示されているＲＤＦタプルを圧縮する方法によって、）ソートされたモートン符号化された行列ペアのデルタをｖａｒ－ｉｎｔ直列化（var-int serialize）するだけでよい。最初の値を０で初期化する代わりにできるだけ小さく保つために、実装はノードのモートン符号化座標を使用する。この座標の計算は、ＢＬを適切にスキャンするために計算されなければならないため、オーバーヘッドではない。
【0140】
テスト
実装は、例えば、約８０億個のＲＤＦトリプルのデータセットであるＭｉｃｒｏｓｏｆｔ Ａｃａｄｅｍｉｃ Ｇｒａｐｈ（非特許文献２４参照）における、グラフデータベースを格納する方法の容量を試験するテストに基づく。そのようなテストにより、開示された格納方法は、動的Ｋ２ ｔｒｅｅ（性能低下および書込み増幅が起こる）、および古典的なＢ＋ Ｔｒｅｅｓを利用した既製データ構造を使用する代替ソリューション（データベースのストレージコストの大幅な増加が起こる）よりも性能が優れることが確認された。
実装は、例えば、約８０億個のＲＤＦトリプルのデータセットであるＭｉｃｒｏｓｏｆｔ Ａｃａｄｅｍｉｃ Ｇｒａｐｈ（非特許文献２４参照）における、グラフデータベースを格納する方法の容量を試験するテストに基づく。そのようなテストにより、開示された格納方法は、動的Ｋ２ ｔｒｅｅ（性能低下および書込み増幅が起こる）、および古典的なＢ＋ Ｔｒｅｅｓを利用した既製データ構造を使用する代替ソリューション（データベースのストレージコストの大幅な増加が起こる）よりも性能が優れることが確認された。
【0141】
本開示によるＸＡＭＴｒｅｅを、参照により本明細書に組み込まれる非特許文献２５に記載されているようなＫ２－ｔｒｅｅの動的バージョンと比較するために、以下のステップによる第１のテストが実施された：
－ ＣｈＥＭＢＬデータセット（非特許文献２６で提供されている）をインポートする。このデータセットは、Ｋ２Ｔｒｅｅで使用できるほど十分に小さい（約５００Ｍトリプル）。
－ ＣｈＥＭＢＬデータセット（非特許文献２６で提供されている）をインポートする。このデータセットは、Ｋ２Ｔｒｅｅで使用できるほど十分に小さい（約５００Ｍトリプル）。
【0142】
－ ＸＡＭＴｒｅｅおよびＫ２Ｔｒｅｅについて隣接行列によってデータベースを格納するためにディスク上で使用されるサイズを比較する。
【0143】
－ 小さな隣接行列（３Ｋトリプル）を含む小さいクエリと大きな隣接行列（約３０～６０Ｍトリプル）を含む大きいクエリ上との経過時間を比較して、Ｋ２Ｔｒｅｅの劣化を強調した。
【0144】
上記のステップのすべての操作は、ＸＡＭＴｒｅｅとＫ２Ｔｒｅｅの両方のデータ構造について同じハードウェア上で行われ、したがって、結果はハードウェアに依存しない。
【0145】
結果は、以下の表５に示されている。
【0146】
【表5】
【0147】
表５に提示された結果では、２列目と３列目の値の比較は、それらの各々の絶対値よりも重要である。これらの結果は、ＸＡＭＴｒｅｅストレージコストが動的ｋ２－ｔｒｅｅと同じ桁の大きさである一方で、大きな問い合わせに対してより良好な問い合わせ時間を達成していることを示す。この実験は、Ｋ２Ｔｒｅｅにより適したデータセットで実行されており、Ｋ２Ｔｒｅｅが使用可能であり、そのより低いストレージコストは、経過時間のゲイン（実験では２０％）に関して好適であり得ることを意味することに留意されたい。
【0148】
テストで使用された小さいクエリ（ｑ０．ｓｐａｒｑｌ）は、以下の通りである：
Ｓｅｌｅｃｔ （ｃｏｕｎｔ（？ｓ） ａｓ ？ｎｂ） ｛ ？ｓ ｃｃｏ：ｈａｓＭｅｃｈａｎｉｓｍ ？ｏ ｝
そして、テストでの大きいクエリ（ｑ１．ｓｐａｒｑｌ）は、以下の通りである：
ＰＲＥＦＩＸ ｒｄｆ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／０２／２２－ｒｄｆ－ｓｙｎｔａｘ－ｎｓ＃＞
ＰＲＥＦＩＸ ｒｄｆｓ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０１／ｒｄｆ－ｓｃｈｅｍａ＃＞
ＰＲＥＦＩＸ ｏｗｌ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／０７／ｏｗｌ＃＞
ＰＲＥＦＩＸ ｘｓｄ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ＃＞
ＰＲＥＦＩＸ ｄｃ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｄｃ／ｅｌｅｍｅｎｔｓ／１．１／＞
ＰＲＥＦＩＸ ｄｃｔｅｒｍｓ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｄｃ／ｔｅｒｍｓ／＞
ＰＲＥＦＩＸ ｆｏａｆ： ＜ｈｔｔｐ：／／ｘｍｌｎｓ．ｃｏｍ／ｆｏａｆ／０．１／＞
ＰＲＥＦＩＸ ｓｋｏｓ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００４／０２／ｓｋｏｓ／ｃｏｒｅ＃＞
ＰＲＥＦＩＸ ｃｃｏ： ＜ｈｔｔｐ：／／ｒｄｆ．ｅｂｉ．ａｃ．ｕｋ／ｔｅｒｍｓ／ｃｈｅｍｂｌ＃＞
ＰＲＥＦＩＸ ｂｉｂｏ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｏｎｔｏｌｏｇｙ／ｂｉｂｏ／＞
ＳＥＬＥＣＴ ？ｓｕｂｓｔａｎｃｅ ？ｐｕｂｍｅｄｉｄ ？ｓｏｕｒｃｅＬａｂｅｌ ？ａｓｓａｙＴｙｐｅ ？ｐｒｏｔｅｉｎ
ＷＨＥＲＥ ｛
？ｓｕｂｓｔａｎｃｅ ｒｄｆ：ｔｙｐｅ ｃｃｏ：Ｓｕｂｓｔａｎｃｅ．
？ｓｕｂｓｔａｎｃｅ ｃｃｏ：ｈａｓＤｏｃｕｍｅｎｔ ？ｄｏｃｕｍｅｎｔ．
？ｄｏｃｕｍｅｎｔ ｂｉｂｏ：ｐｍｉｄ ？ｐｕｂｍｅｄｉｄ．
？ｄｏｃｕｍｅｎｔ ｃｃｏ：ｈａｓＡｓｓａｙ ？ａｓｓａｙ．
？ａｓｓａｙ ｃｃｏ：ａｓｓａｙＴｙｐｅ ？ａｓｓａｙＴｙｐｅ．
？ａｓｓａｙ ｃｃｏ：ｈａｓＳｏｕｒｃｅ ？ｓｏｕｒｃｅ．
？ｓｏｕｒｃｅ ｒｄｆｓ：ｌａｂｅｌ ？ｓｏｕｒｃｅＬａｂｅｌ．
？ａｓｓａｙ ｃｃｏ：ｈａｓＴａｒｇｅｔ ？ｔａｒｇｅｔ．
？ｔａｒｇｅｔ ｃｃｏ：ｈａｓＴａｒｇｅｔＣｏｍｐｏｎｅｎｔ ？ｔａｒｇｅｔｃｏｍｐｏｎｅｎｔ．
？ｔａｒｇｅｔｃｏｍｐｏｎｅｎｔ ｃｃｏ：ｔａｒｇｅｔＣｍｐｔＸｒｅｆ ？ｐｒｏｔｅｉｎ．
？ｐｒｏｔｅｉｎ ａ ｃｃｏ：ＵｎｉｐｒｏｔＲｅｆ
｝
Ｓｅｌｅｃｔ （ｃｏｕｎｔ（？ｓ） ａｓ ？ｎｂ） ｛ ？ｓ ｃｃｏ：ｈａｓＭｅｃｈａｎｉｓｍ ？ｏ ｝
そして、テストでの大きいクエリ（ｑ１．ｓｐａｒｑｌ）は、以下の通りである：
ＰＲＥＦＩＸ ｒｄｆ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／１９９９／０２／２２－ｒｄｆ－ｓｙｎｔａｘ－ｎｓ＃＞
ＰＲＥＦＩＸ ｒｄｆｓ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０１／ｒｄｆ－ｓｃｈｅｍａ＃＞
ＰＲＥＦＩＸ ｏｗｌ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００２／０７／ｏｗｌ＃＞
ＰＲＥＦＩＸ ｘｓｄ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ＃＞
ＰＲＥＦＩＸ ｄｃ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｄｃ／ｅｌｅｍｅｎｔｓ／１．１／＞
ＰＲＥＦＩＸ ｄｃｔｅｒｍｓ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｄｃ／ｔｅｒｍｓ／＞
ＰＲＥＦＩＸ ｆｏａｆ： ＜ｈｔｔｐ：／／ｘｍｌｎｓ．ｃｏｍ／ｆｏａｆ／０．１／＞
ＰＲＥＦＩＸ ｓｋｏｓ： ＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００４／０２／ｓｋｏｓ／ｃｏｒｅ＃＞
ＰＲＥＦＩＸ ｃｃｏ： ＜ｈｔｔｐ：／／ｒｄｆ．ｅｂｉ．ａｃ．ｕｋ／ｔｅｒｍｓ／ｃｈｅｍｂｌ＃＞
ＰＲＥＦＩＸ ｂｉｂｏ： ＜ｈｔｔｐ：／／ｐｕｒｌ．ｏｒｇ／ｏｎｔｏｌｏｇｙ／ｂｉｂｏ／＞
ＳＥＬＥＣＴ ？ｓｕｂｓｔａｎｃｅ ？ｐｕｂｍｅｄｉｄ ？ｓｏｕｒｃｅＬａｂｅｌ ？ａｓｓａｙＴｙｐｅ ？ｐｒｏｔｅｉｎ
ＷＨＥＲＥ ｛
？ｓｕｂｓｔａｎｃｅ ｒｄｆ：ｔｙｐｅ ｃｃｏ：Ｓｕｂｓｔａｎｃｅ．
？ｓｕｂｓｔａｎｃｅ ｃｃｏ：ｈａｓＤｏｃｕｍｅｎｔ ？ｄｏｃｕｍｅｎｔ．
？ｄｏｃｕｍｅｎｔ ｂｉｂｏ：ｐｍｉｄ ？ｐｕｂｍｅｄｉｄ．
？ｄｏｃｕｍｅｎｔ ｃｃｏ：ｈａｓＡｓｓａｙ ？ａｓｓａｙ．
？ａｓｓａｙ ｃｃｏ：ａｓｓａｙＴｙｐｅ ？ａｓｓａｙＴｙｐｅ．
？ａｓｓａｙ ｃｃｏ：ｈａｓＳｏｕｒｃｅ ？ｓｏｕｒｃｅ．
？ｓｏｕｒｃｅ ｒｄｆｓ：ｌａｂｅｌ ？ｓｏｕｒｃｅＬａｂｅｌ．
？ａｓｓａｙ ｃｃｏ：ｈａｓＴａｒｇｅｔ ？ｔａｒｇｅｔ．
？ｔａｒｇｅｔ ｃｃｏ：ｈａｓＴａｒｇｅｔＣｏｍｐｏｎｅｎｔ ？ｔａｒｇｅｔｃｏｍｐｏｎｅｎｔ．
？ｔａｒｇｅｔｃｏｍｐｏｎｅｎｔ ｃｃｏ：ｔａｒｇｅｔＣｍｐｔＸｒｅｆ ？ｐｒｏｔｅｉｎ．
？ｐｒｏｔｅｉｎ ａ ｃｃｏ：ＵｎｉｐｒｏｔＲｅｆ
｝
【0149】
第２のテストは、約８０億個のトリプルからなるＭｉｃｒｏｓｏｆｔ Ａｃａｄｅｍｉｃ Ｋｎｏｗｌｅｄｇｅ Ｇｒａｐｈ（ＭＡＧ）データセット（ｈｔｔｐｓ：／／ｍａｋｇ．ｏｒｇ／ｒｄｆ－ｄｕｍｐｓで提供されている）のより大きなデータセットを用いて実行された。第２のテスト結果は、ＸＡＭＴｒｅｅデータ構造では約２０時間でＭＡＧをインポートすることを可能にする（取込みスループットは１１３４２８トリプル／秒）のに対し、動的Ｋ２ｔｒｅｅでは同じハードウェアで４０時間後でもインポートが終了しないことを示している。それにより、Ｋ２Ｔｒｅｅは、テストの失敗閾値として設定された５００００トリプル／秒以上のスループットの基準に合格しなかった。第２のテストの結果は、ＸＡＭＴｒｅｅがグラフデータベースのサイズに応じてスケールするが、（動的な）Ｋ２Ｔｒｅｅはスケールしないことを示している。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6A】
【図6B】
【外国語明細書】