この質問は、 Jena OntModel の変更のシリアル化に関するrcreswickの質問に関連しています。ソケットを介して同期を維持する必要がある 2 つ (またはそれ以上) のマシンに Jena モデルがあります。対処する必要がある主な問題は、モデルに匿名ノード (bnode) が含まれる可能性があることです。これは、任意のモデルに由来する可能性があります。
質問: 私はここで正しい方向に進んでいますか? それとも、私が考慮していない、より優れた、より堅牢なアプローチがありますか?
この問題に対する 3 つのアプローチを考えることができます。
- 完全なモデルをシリアル化します: これは、小規模な更新を同期するには法外にコストがかかります。また、どちらのマシンでも変更が発生する可能性があるため、マシン B のモデルをマシン A のシリアル化されたモデルと単純に置き換えることはできません。それらをマージする必要があります。
- 部分モデルをシリアライズする: ソケット経由で送信する必要がある変更のみを含むシリアライゼーション専用のモデルを使用します。このアプローチには、モデルから削除されたステートメントを表すための特別な語彙が必要です。おそらく、モデルをマシン A からマシン B にシリアル化すると、匿名ノード ID はマシン A に固有になりますが、マシン B で作成された匿名ノードの ID と重複する可能性があります。したがって、匿名ノードの名前を変更し、マッピングを保持する必要があります。将来の変更を正しく処理するために、マシン A の anon ID からマシン B の ID に変更します。
- 個々のステートメントをシリアル化する: このアプローチには特別な語彙は必要ありませんが、それほど堅牢ではない可能性があります。まだ遭遇していない匿名ノード以外の問題はありますか?
- グローバルに一意の bnode ID を生成する (NEW) : ID の前に一意のマシン ID を付けることで、匿名ノードのグローバルに一意の ID を生成できます。残念ながら、 Jena に独自の ID ジェネレーターではなく私の ID ジェネレーターを使用するように指示する方法がわかりません。これにより、bnode ID を再マッピングすることなく、個々のステートメントをシリアル化できます。
この議論をもう少し根拠づける例を次に示します。次のように表されるマシン A のリストがあるとします。
_:a rdf:first myns:tom
_:a rdf:rest rdf:nil
このモデルをマシン A からマシン B にシリアル化します。ここで、マシン B には ID 'a' の (関連のない) 匿名ノードが既にある可能性があるため、ID 'a' を新しい ID 'b' に再マップします。
_:b rdf:first myns:tom
_:b rdf:rest rdf:nil
マシン A でリストが変更されます。
_:a rdf:first myns:tom
_:a rdf:rest _:b
_:b rdf:first myns:dick
_:b rdf:rest rdf:nil
マシン B はこれまでマシン A の ID 'b' に遭遇したことがないため、マシン A の ID 'b' から新しい ID 'c' への新しいマッピングを追加します。
_:b rdf:first myns:tom
_:b rdf:rest _:c
_:c rdf:first myns:dick
_:c rdf:rest rdf:nil
2 台以上のマシンでは、問題はさらに複雑になります。たとえば、3 台目のマシン C がある場合、マシン A の匿名ノード「a」とは異なる独自の匿名ノード「a」を持つことができます。したがって、マシン B は、一般的なリモート ID からローカル ID へのマップだけでなく、他の各マシンの匿名ノード ID からローカル ID へのマップを保持する必要があります。入ってくる変更を処理するとき、ID を正しくマップするために、変更がどこから来たのかを考慮する必要があります。