このドキュメントは
Limiting the damage of an inconsistency
http://www.w3.org/DesignIssues/Inconsistent.html
の和訳です。
この文書には和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版文書を参照して下さい。

Tim Berners-Lee

Date: 1998, last change: $Date: 2000/01/24 14:48:22 $
Status: personal view only. Editing status: first draft.

Up to Design Issues

Semantic Web


Inconsistent data 矛盾するデータ

この莫大な古典的なロジックの集まりがその第一の矛盾に出会うときに何が起きるのか?多くの人が尋ねる。確かに一度あなたがAというステートメントと、Web上のどこかにあるAではない別のを持つと、システム全体は離れ離れになってしまわないか?あなたはあなたが欲しい何かを推測できるのか?

この恐れはもちろんまったく妥当である−つまり全世界の全てのアサーションが同じ立場であるとみなされるかどうかということになる。ある人は、RDFパーサは任意の事実のために単に全てのWeb上のXMLドキュメントを探し、それらを大量の確からしく思われるアサーションのセットに追加するものと考えている。これは現実的なシステムが実際に動作する様子ではない。

Web上では、表現の中に事実が言明されているかもしれない。その表現は式の一部かもしれない。式は否定を伴うかもしれない、そして引用を伴うかもしれない。全ての式はあるドキュメントをパースすることによって見つかる。Web上のどんなドキュメントでも信じるのに優先すべき理由はない。ドキュメントを正しいと思う理由は、ドキュメントに関する情報(メタデータ)の中に見つかるだろう。そのメタデータはドキュメントを保証するものかもしれない−発見された別のRDFステートメントは今度は別のドキュメントを、というように。

[@@ここに図が必要]

現実のシステムは後方にも前方にも(また両方にも)働くかもしれない。私は、前方に働くことを、妥当なデータとして使われる他のページを次々と指し示すところから働くコンフィギュレーションページが与えられたシステムとみなす。私は、後方に働くことを、クエリーに対する答えを探すときに、与えられた用語を少しでも言及したドキュメントを見つけるためのグローバルなインデックスを見るシステムとみなす。そしてそれは、クエリーに対する答えのために生じたドキュメントを捜す。データが出所から直接もしくは間接的に引き出されているかどうか、答えが見て確認していないということがわかっているときだけ、信用のためにそれは据えられる。

デジタル署名(trustを見よ)はもちろん全てのプロセスにセキュリティの観念を付加している。最初の段階は、ドキュメントは正しいと思われたときのチェックサムが与えられることなしでは保証されない。第二の段階は式のより強力なルールを明示することである。

”キー57832498437で署名されている限り、任意のドキュメントが言うことは何でも”
実際問題として、個々の権威者は特定の目的に限って信用される。セマンティックWebはこれをサポートしなければならない。次の行に沿って正しいと思われた情報をあなたが制限することができなければならない。
”キー32457934759432で署名されている限り、任意のドキュメントが式、xxxxはW3Cのメンバであると言うことは何でも”
例えば
”キー3213123098129で署名されている限り、任意のドキュメントが式「aはIBMの従業員である」と言うことは何でも”

Limiting inference 推論の制限

ここに選択肢がある。そして私は今どちらがより私が気に入るか確信できない。一方は正確に次のように言うことである。
”キー32457934759432で署名されている限り、任意のドキュメントが式、xxxxはW3Cのメンバであると言うことは何でも”
もう一方は次のように言うことである。
”式 xxxxでキー32457934759432で署名された情報から推論できるものは何でも”
最初のケースでは、特有の方法で表現されたステートメントのための勝手な必要条件を作っている。これは不必要に官僚的で、一定に取り扱うことはより難しい。普通は我々は式の任意のセットと、そこから推論され得る別のセットを交換したくなる。だがこの場合、我々がそれをパターンでマッチングさせる必要があるときでも、現在の式を保つ必要がある。これはとてもやっかいである。

第二のケースでは、我々は矛盾の罠の犠牲となる。ひとたび、与えられたキーによって署名された情報から矛盾した2つのステートメントが演繹されると、そのキーで署名された情報から何でも推論されてしまう:そのキーは完全に壊れている。もちろん、そのキーだけ壊れていると、信用できるシステムは、そのキーを信用しなければならないという理由を取り除くことができる。しかしながら攻撃をくらったシステムは、太陽が西から昇ると確信する前に何が起きていたか理解できないかもしれない。

システム全体を通して矛盾のない方法で処理された情報を許しながら、キーにおける信用できる領域の制限をする方法はあるのか?はい−おそらく−たくさんある。この問題を(一部)解決するために、制限されたロジックを使う各KRシステムはそうする。私達は、「推論され得る」が、使われるかもしれない推論ルールのタイプになる資格があるとする。このことが意味するのは、一般的な証明エンジンが、ルールの具体化されたバージョンを通して働くか、セットを知る−各証明エンジンを具体化させるかのいずれかでなければならないということである。たぶん我々は一つだけ必要だろう。

Expiry 満了

トータス:何時か、アキレス?

アキレス:10時5分だ、友よ。[彼らは1分間談笑する]

トータス:何時か、アキレス?

アキレス:10時6分だ、トータス。

トータス:でも、アキレス、おまえはちょうど1分前に私に10時5分だといったじゃないか。一体またおまえを信じて良いのだろうか?

時−変化する情報は明きらかな矛盾の原因の一つである。人々やドキュメントは状態を変える。時代遅れになってしまうかもしれない情報の推定の基礎をどのように置くのか?

この不可分な要素の1つは、全てに明確もしくは暗黙の有効期間満了日をつけることである。HTTPクライアントにサーバがリソースを送信するときはいつでも、有効期間満了日を与えることができる。クライアントはこれを辿ることができ、そして期日がきたときに、同じことを言っているもっと最近のコピーが得られない限り、そのドキュメントからの全ての推論をキャンセルすることを保証する。人間の言葉で、「雨だ」とあなたは言うかもしれないが、セマンティックWebでは、次のように完全に修飾された方法で伝えられるでしょう。「2000年1月24日月曜日 09:41:06 EST ダブリン空港にある測定計器5はこの1時間に降り続いた雨を読み取った」。(ファジーシステムは「ダブリンは雨だ」と結論付けるであろう、そして古典的な論理システムでは「ダブリンの少なくとも一箇所で少なくとも一度雨が降った」とするだろう!)

私はKIFの人々が時の食い違いに対する完全なボキャブラリを開発したことを知っている[Lehrmann, SW meeting in DC] (sp?)。

別のテクニックは、現実のシステムに存在するルーズさを目に見えるようにすることである。次のように言う代わりに

W3Cのどのメンバ組織のどんな従業員でも登録して良い
あなたは正式に登録エンジンに言う。
ここ2ヶ月間のある時点でW3Cメンバだった組織のここ2ヶ月間のある時点で従業員だったどんな人でも登録して良い。
別の言葉で言えば、組織がメンバシップを失っても、システムはその情報を直ちに伝えることをサポートする必要がないということである。

時を意識した推論システムがあるでしょうし、時を意識しない推論システム、それは有効期間満了日を持ったデータでその結果は入ってくるデータの有効期間の交差する期間内に利用されるというものがあると私は思う。実際に、時を意識した推論システムは、入れ子になった時を意識しない推論システムを含むかもしれないし、そしてたぶんその逆も成り立つだろう。


Up to Design Issues

Tim BL