ナレッジグラフ

実務では

この分野が曖昧にし続けている区別を最もすっきりと押さえる方法はこうだ。オントロジーはスキーマであり、ナレッジグラフはそれに準拠して実際に埋められたインスタンスデータである。オントロジーは「作業指示はデバイスに紐づき、デバイスは顧客に属する」と述べる。ナレッジグラフは、実際の数百万件の作業指示、デバイス、顧客と、それらの間のエッジを保持する。実務では、グラフは OWL オントロジーを上に載せた RDF トリプルとして保存されるか、Neo4j のようなエンジンのプロパティグラフとして保存される。そして本番環境のグラフの多くは、一度も書き下されたことのないオントロジーのもとで動いている——同じグラフの中で二つのチームが互換性のない「顧客」の定義を持つに至るのは、まさにこのためだ。

つながりの形をした問いに対しては、ナレッジグラフが正しい道具であり、他に匹敵するものはない。不正リング、実質的支配者の連鎖、サプライチェーンの依存関係、ネットワーク全体にわたる影響分析、十数個のソースシステムにまたがるエンティティ解決、そして「ここから 4 ホップ先にあるのは何か」という形のあらゆる問いは、グラフにとってはネイティブであり、リレーショナルな結合では扱いにくく、ときには不可能である。それが問題であるなら、答えはグラフデータベースであり、どのアプリケーションプラットフォームもその代わりにはならない。

ナレッジグラフがセマンティックレイヤーと共有する限界は同じものだ。ナレッジグラフは圧倒的に読み取りのための構造である。物事がつながっていることは記録するが、誰がそれらを変更してよいか、どの操作が許可されるか、変更がどんな監査記録を残すかは宣言しない。ObjectStack はつながりを反対側から扱う。関係はアプリケーション自身のメタデータの中で、オブジェクト上の型付きフィールドとして宣言される。そのためビジネスのグラフは、アプリケーションがすでに実行している定義から自然に導かれ、同期を保たなければならない第二のストアにはならない。しかもその定義はあなたのリポジトリにあるファイルなので、他社のプラットフォームの中にあるグラフではなく、オープンなビジネスオントロジーとなる。これは所有権とガバナンスについての主張であって、グラフ分析についての主張ではない。ObjectStack はグラフデータベースではなく、深いマルチホップのトラバーサルで勝とうとはしていない。