1

歴史上の人物について、さまざまな情報源が語っていることを記録したいと思います。すなわち

  • ウィキペディアのウェブサイトによると、スーザン B. アンソニーは 1820 年 2 月 15 日に生まれ、好きな色は青でした。
  • 闘争の世紀という本には、スーザン・B・アンソニーは1820年2月12日に生まれ、彼女の好きな色は赤だったと書かれています
  • 女性参政権の歴史という本は、スーザン・B・アンソニーは1820年2月15日に生まれ、彼女の好きな色は赤で、彼女はエイブラハム・リンカーンの2番目のいとこであったと述べています

また、研究者には、これらの情報源が行っている個々の主張について、たとえばパーセンテージで自信を示すことができるようにしてほしい. すなわち

  • ユーザー A は、スーザン B. アンソニーが 1820 年 2 月 15 日に生まれたことを 90% 確信しています。彼女の好きな色が青であるという確信は 75%、エイブラハム リンカーンの従兄弟であるという確信は 30% でした。
  • ユーザー B は、スーザン B. アンソニーが 1820 年 2 月 12 日に生まれたことを 30% 確信しています。彼女の好きな色が青であるという確信は 60%、エイブラハム リンカーンの従兄弟であるという確信は 10% でした。

次に、各ユーザーに Susan B. Anthony のビューを表示して、彼女の誕生日、好きな色、およびユーザーが真実である可能性が最も高いと考える関係を表示するようにします。

私はリレーショナル データベース データストアも使用したいと考えています。これを行うには、ユーザーが信頼を表明できるようにするアトミック ファクトの個々のタイプごとに個別のテーブルを作成することが考えられます。この例では、合計で 8 つのテーブルがあり、3 つの個別のアトミック ファクトに対して 3 つの個別のテーブルがあります。

Source(id)
Person(id)

Claim(claim_id, source, FOREIGN KEY(source) REFERENCES Source(id) )
Alleged_birth_date(claim_id, person, birth_date, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES person(id))
Alleged_favorite_color(claim_id, person, color, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES person(id)) 
Alleged_kinship(claim_id, person, relationship type, kin, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES Person(id))

User(id)
Confidence_in_claim(user, claim, confidence, FOREIGN KEY(user) REFERENCES User(id), FOREIGN KEY(claim) REFERENCES claim(id))

これは、実際には多くの種類のアトミック ファクトを記録する必要があるため、非常に急速に複雑になるように感じます。これを行うためのより良い方法はありますか?

これは、Martin Fowler が「矛盾した観察」と呼んでいる問題と同じだと思います。

4

4 に答える 4

3

「ファクト」テーブルといくつかの「ディメンション」テーブルを中心としたスター スキーマ モデルを試す必要があります。これは十分に調査されたモデルであり、多くのデータベース最適化があります。

claim_fact(source_id, person_id, user_id, details_id, weight)

Source_dimension(id, 名前)

Person_dimension(id, 名前)

User_dimension(id、名前)

details_dimension(id, name NOT NULL, color NULLABLE, 親族関係 NULLABLE, birthday NULLABLE)

すべてのクレームには、ソース、人物、ユーザー、および詳細が含まれます。詳細の NAME 値は、「親族」、「誕生日」などの値になります。

これは (OLTP 構造ではなく) OLAP スキーマであり、完全には正規化されていないことに注意してください。スター スキーマへのクエリは、Data Warehousing 用に構成された DBMS によって高度に最適化されるため、この利点は、冗長性が原因で発生する可能性のある問題を上回ります。

推奨資料: データ ウェアハウス ツールキット (Kimball など)

于 2009-05-20T21:30:52.850 に答える
2

RDFはこれに最適です。通常、メタデータのフォーマットとして説明されています。しかし実際には、これはトリプレットの「アサーション」のグラフ モデルです。

全体の「セマンティック Web」のアイデアは、RDF で多くの事実を公開することであり、検索エンジンは、統合されたグラフを走査して関係を見つける推論エンジンになります。

トリプレットを参照するメカニズムもいくつかあるので、主張の起源 (誰が言った?)、いつ主張されたのか (いつ彼はそれを言ったのか?)、またはそれをどれだけ信じているかなど、主張について何かを言うことができます。真実であることなど

大きな例として、OpenCycの「常識知識ベース」全体が RDF でクエリ可能です

于 2009-05-20T21:21:38.173 に答える
1

使いたいのは「プロパティバッグ」だと思います。記述したい個々のタイプの事実をモデル化する代わりに、ID、「キー」(この場合は「親族関係」などの主張された情報)、および「値」を含むテーブルが必要です。 " (この場合は、申し立てられた値 ("Abraham Lincoln など)")。次に、請求者をそのテーブルに関連付ける 2 番目のテーブルを、その情報に対する彼らの信頼レベルとともに作成します。そのテーブルは次のようになります。ソースの ID、プロパティの ID、およびソースが情報に対して持っている信頼度を単純に取得します。このようにして、多くの情報または少ない情報を含むソースを取得できます。また、異なるソースをモデル化することもできます。特定の属性にさまざまなレベルの信頼性を持つ。

これは、相互参照したいオプションの情報が大量にある場合などの状況では、かなり標準的なソリューションです。

于 2009-05-20T21:22:42.833 に答える
0

これは非常に複雑になるように感じます

冗談じゃない。オントロジーと知識表現に関する研究をご覧ください。

于 2009-05-20T21:22:07.470 に答える