Apache Fusekiは「モルモット」として機能しますが、他のSPARQLエンドポイントにも同じ原理を適用できます。
アーキテクチャと機能
製品自体の中に入れない場合、計画を実装する唯一の方法は、アクセスポイントのプログラムインターフェイスの上にプロキシレイヤーを作成することです。 これが私たちがやったことです。 サービスに宛てられたすべてのSPARQLクエリはプロキシを通過し、そこで分析され、さらに処理されます。
プロキシにアクセスするとき、アプリケーションは特定のユーザーアカウントでログインできます。このため、標準プログラムインターフェイスを少し拡張する必要があり、標準内のまま匿名でアクセスできます。
プロキシには独自のバックエンドがあり、オントロジークラスへのユーザーアクセス権（ユーザーグループ）を構成できます。 権利は継承されます。 アクセスレベルは、次の値に設定できます。
- アクセス権なし;
- 読書
- 適度に変化します。
- 変更します。
各オントロジーオブジェクトが同時に任意の数のクラスのインスタンスになることができることは明らかです（継承を考慮することを含む）。 親クラスに適用可能なすべての権利オプションのうち、最も厳しいものが選択されます。
クラスおよびプロパティの定義を編集する機能は、owl：Classなどの標準タイプへのアクセス権を付与することにより規制されています。
私たちの場合、オントロジーに関する集団作業の可能性を確保することが重要でした。 「モデレートの変更」権限レベルにより、ユーザーはDELETE / INSERTリクエストを実行できますが、その結果はすぐにデータベースに適用されるのではなく、適切な権限を持つユーザーに承認のために送信されます。 一日一回、バックエンドは受け取った変更をそのようなユーザーに通知し、ユーザーはそれらを適用または拒否する機会があります。
ユーザーがオントロジーに対して行ったすべての変更は、バックエンドサービスデータベースにあるログに保存されます（リレーショナル。アクセス権の設定が保存されます）。 その結果、各オントロジーオブジェクトのすべてのプロパティの変更履歴を作成し、各変更の日付と作成者を示すことができます。
アクセス権に戻る：プロキシに到着したリクエストは、実行前または実行後に権利チェックに合格します。 クエリがデータサンプリング（SELECT、ASK、CONSTRUCT）を目的としている場合、現在のユーザーがアクセスできないオブジェクトを含むソリューションはその結果セットから除外されます（クエリが匿名の場合、クラスインスタンスで完全に構成されるソリューションのみが返されます。権利の制限はありません）。 リクエストのタイプがDELETE / INSERT / UPLOADの場合、影響を受けるトリプレットのセットが最初に決定され、少なくとも1つに編集アクセス権がない場合、リクエスト全体がキャンセルされます。 もちろん、プロキシで機能するフロントエンドは、エラーメッセージと、変更が適度になったという警告を解釈するために「教えられる」必要がありました。
ペアのDELETE / INSERT要求が検出され、INSERT要求がキャンセルされると（what if？）、ペアのDELETEもキャンセルされます。 一般に、プロキシを記述するとき、いくつかの興味深い回避策を使用する必要がありました。 たとえば、SELECTなどのクエリへの応答には、アクセスが許可されていないオブジェクトが含まれていない場合がありますが、それらはソリューションの計算に関与します。 このような状況は、たとえば、リクエストを実行するときに発生します
SELECT ?prop WHERE { ?object <has_property_1> "some value". ?object <has_property_2> ?prop }
ユーザーがオブジェクトの一部オブジェクトへのアクセス権を持っていない場合。 プロキシはこのようなリクエストを展開し、利用可能なオブジェクトのみのPropプロパティを返します。 同様の処理を、値COUNT（*）を返すクエリに適用する必要がありました。
上記のすべての後、トリガーの機能を実装することはすでに非常に簡単でした。 トリガーは、特定のクラスのインスタンスに影響を与える場合にデータを変更する要求の後に実行される特定のプロシージャです。 このプロジェクトでは、トリガーを使用して外部システムに変更を通知します。メッセージはバスに送信されます。 ただし、たとえば、データベース自体のカスケード変更に同じメカニズムを使用できます。
結果とパフォーマンス
機能面では、意図したすべての結果を達成しました。 システムは、アクセスポイントに要求を送信するアプリケーションに関係なく、アクセス権の制御を提供し、データの変更に関する通知も送信します。 変更ログを使用すると、任意の時点でオブジェクトの状態を復元できます。 「確認付き編集」の機能は、オントロジーの変更の本格的な節度を提供します。
追加の処理がクエリ実行の速度にどの程度影響するかを調べることは残っています。 まず、製品は他のいくつかの情報システムのマスターデータカタログとして機能するため、SELECTクエリの速度が影響を受けないようにすることに関心がありました。
実際の負荷の下で受信したSELECTクエリと、プロキシが実行する実際のSPARQLアクセスポイントへのクエリを分析した結果、それらの半分以上が「AはBのサブクラス」、「AはクラスBのメンバー」のような単純な式であることがわかりました「。 もちろん、このようなクエリは簡単にキャッシュでき、トリガーメカニズムを使用して実際のデータベースの内容を変更するときにキャッシュを更新します。 その結果、プロキシは実際のアクセスポイントに頼ることなく、この種の要求（およびより複雑な要求）に応答し、アクセス権を計算するアルゴリズムでキャッシュを広く使用します。 結果は予想を上回りました。実際の負荷の下では、権限制御なしで実際のエンドポイントに直接アクセスする場合よりも、システムの動作がわずか13％遅くなります。
データ変更リクエストでは、状況はそれほど楽観的ではありません。DELETE/ INSERT（特にUPLOAD）の処理ははるかに複雑で最適化できないため、実行は6倍遅くなります。 さて、機能と引き換えにパフォーマンスの一部を失い、稼働中のシステムでこれを我慢しなければなりませんでした。