問題タブ [ontology]

RDF グラフをかなり有用なグラフィック形式でレンダリングするツールを探しています。グラフィック形式の主な目的は、PowerPoint スライドに含めること、または経営陣のレビューのために大きなプロッターに印刷することです。

私は現在 TopBraid Composer を使用していますが、これは単一のエンティティの視覚化にはかなり適していますが、グラフ全体を (全体として) 視覚化する明確な方法がないようです。

この問題に対する良い解決策を知っている人はいますか?

あるオントロジーから別のオントロジーへの T-Box 構造からの宣言的マッピングを定義できるツールを知っている人はいますか?実行すると、あるオントロジーのフォームから別のオントロジーのフォームへの A-Box インスタンス データの変換に影響を与えることができますか?

私は最近、自分のニーズを満たすためにそのようなツールを作成しましたが、車輪を再発明したかどうか疑問に思っていました.

私はオントロジー処理ツールを構築しており、人々が現実の世界でそれらを構築して使用しているので、さまざまなフクロウのオントロジーの多くの例が必要です。私はCycのような基本的なオントロジーについて話しているのではなく、より小さなドメイン固有のオントロジーについて話しているのです。

ここでは、パフォーマンスではなく、インストール/使用の容易さが最も重要な要素です。

大規模なデータセットは想定されていないため、小規模で問題ありません。

いくつかのJenaモデル（具体的にはOntModels）をソケット間で同期させる必要があります。これは、一度に1つずつ変更したいと思います（さまざまな理由から、OntModelsに追加または削除された各ステートメントはまた、JESSルールベースを適応させます。）OntModelsでadd/removeイベントをリッスンし、追加/削除されたステートメントと、ステートメントが追加または削除されたことを示すChangeTypeをラップする単純なイベントインスタンスを作成できますが、ステートメントのシリアル化は問題。

残念ながら、私が見つけたJENAシリアル化のドキュメントはすべて、モデル全体をxml / rdf / n3 /などにシリアル化することに関連しています。ステートメントは（とにかく、あるレベルでは）文字列のトリプルであるため、ステートメントレベルでデータをシリアル化します。ただし、Jenaは、「正しいことを行う」プレーンな文字列を使用してステートメントを作成するためのAPIを提供していないようです。型付きリテラルで問題が発生します。例えば：

私はステートメントを作成することができます：

しかし、私が取得できる文字列バージョンは次のようになります。

（^^の前に "がないことに注意してください）

リテラルは正規表現で解析できるため、これはそれほど問題にはなりませんが、適切なリテラルを使用してステートメントを作成することはできませんでした。明らかなアプローチ（ModelCon.createStatement（Resource、Property、String））は、渡された文字列の完全な値を使用して、型指定されていない文字列リテラルを生成します。

個々のイエナステートメントを確実にシリアル化（そしてもちろん逆シリアル化）する方法を知っている人はいますか？

RDF スキーマには、事前に定義された規範が存在します。RDF データ インスタンスに RDF スキーマ スニペ​​ットが埋め込まれているかどうか疑問に思っていました。サブジェクト/オブジェクトの名前でもあるクラスの名前のようなもの。

この質問は、 Jena OntModel の変更のシリアル化に関するrcreswickの質問に関連しています。ソケットを介して同期を維持する必要がある 2 つ (またはそれ以上) のマシンに Jena モデルがあります。対処する必要がある主な問題は、モデルに匿名ノード (bnode) が含まれる可能性があることです。これは、任意のモデルに由来する可能性があります。

質問: 私はここで正しい方向に進んでいますか? それとも、私が考慮していない、より優れた、より堅牢なアプローチがありますか?

この問題に対する 3 つのアプローチを考えることができます。

1. 完全なモデルをシリアル化します: これは、小規模な更新を同期するには法外にコストがかかります。また、どちらのマシンでも変更が発生する可能性があるため、マシン B のモデルをマシン A のシリアル化されたモデルと単純に置き換えることはできません。それらをマージする必要があります。
2. 部分モデルをシリアライズする: ソケット経由で送信する必要がある変更のみを含むシリアライゼーション専用のモデルを使用します。このアプローチには、モデルから削除されたステートメントを表すための特別な語彙が必要です。おそらく、モデルをマシン A からマシン B にシリアル化すると、匿名ノード ID はマシン A に固有になりますが、マシン B で作成された匿名ノードの ID と重複する可能性があります。したがって、匿名ノードの名前を変更し、マッピングを保持する必要があります。将来の変更を正しく処理するために、マシン A の anon ID からマシン B の ID に変更します。
3. 個々のステートメントをシリアル化する: このアプローチには特別な語彙は必要ありませんが、それほど堅牢ではない可能性があります。まだ遭遇していない匿名ノード以外の問題はありますか?
4. グローバルに一意の bnode ID を生成する (NEW) : ID の前に一意のマシン ID を付けることで、匿名ノードのグローバルに一意の ID を生成できます。残念ながら、 Jena に独自の ID ジェネレーターではなく私の ID ジェネレーターを使用するように指示する方法がわかりません。これにより、bnode ID を再マッピングすることなく、個々のステートメントをシリアル化できます。

この議論をもう少し根拠づける例を次に示します。次のように表されるマシン A のリストがあるとします。

このモデルをマシン A からマシン B にシリアル化します。ここで、マシン B には ID 'a' の (関連のない) 匿名ノードが既にある可能性があるため、ID 'a' を新しい ID 'b' に再マップします。

マシン A でリストが変更されます。

マシン B はこれまでマシン A の ID 'b' に遭遇したことがないため、マシン A の ID 'b' から新しい ID 'c' への新しいマッピングを追加します。

2 台以上のマシンでは、問題はさらに複雑になります。たとえば、3 台目のマシン C がある場合、マシン A の匿名ノード「a」とは異なる独自の匿名ノード「a」を持つことができます。したがって、マシン B は、一般的なリモート ID からローカル ID へのマップだけでなく、他の各マシンの匿名ノード ID からローカル ID へのマップを保持する必要があります。入ってくる変更を処理するとき、ID を正しくマップするために、変更がどこから来たのかを考慮する必要があります。

匿名ノード ID を生成するための Jena のデフォルトの方法をオーバーライドする方法はありますか?

理想的には、ID を生成するファンクタを Jena に渡して、ID をグローバルに一意にする (単にマシンに一意にするだけでなく) ようにしたいと考えています。ファンクターは、AnonId が構築されるたびに使用する必要があります。

これは私の以前の質問に多少関連しています。

編集: AnonId には id パラメータを取るコンストラクタがあることがわかりました。このコンストラクターを至る所で呼び出すことを避け、代わりに ID の生成方法を Jena に (1 回) 伝えるだけにしたいと考えています。

編集2 :そのコンストラクターをあちこちで呼び出すことを気にしなくても、アクセスできないライブラリコードによって匿名ノードが作成される可能性があるため、それは不可能かもしれません。

OWLオントロジーからアセンブリーを構築していますが、オントロジーを解析すると、タイプが宣言され、いくつかの値が指定されている「データ型プロパティー」でエラー・メッセージが発生します。Protegev3.4を使用してオントロジーを作成しました。

たとえば、エラーを発生させるデータ型プロパティの1つは、タイプが「string」で値が「English＆Farsi」のような「Language」です。以下に、protegeによって作成された参照を示します。

そして、「Language」プロパティは以下に言及されています：

OWLGrinderにオントロジーを1つ追加するだけです。このエラーは、以下を生成するときに発生します。

「生成」ボタンを押すたびに、「_：bnode」の前の数字が変わります。「Language」プロパティから値を削除すると、次のDataTypeプロパティに関連する別のエラーが発生します。これは、定義されている（そしていくつかの値が指定されている）すべてのDataTypeプロパティがOWLGrinderでエラーを起こしていることを意味します。

誰かがこのエラーを処理するために私を導くことができるかどうか疑問に思いました。