12

私は Prolog を使用して、最も単純な形式のデータ (事実) 以上を処理することに取り組んでおり、経験豊富な Prologers からのガイダンスを探しています...

データや事実を動的に管理したい場合、次のようないくつかの主要な選択肢があります。

  • オレゴン州プロローグでデータをアサーションとして管理
  • オレゴン州プロローグからのデータベースへのインターフェース
  • おそらく両方の組み合わせ

Prolog で事実をアサーションとして管理する場合、それらの事実を表現する最善の方法についても質問があります。person名、姓、年齢を持つ who があるとします。私はそれを次のように断言できます：

person(first_name(_), last_name(_), age(_)).

または、人の属性が何であるかについて暗黙の仮定を持っています。

person(_, _, _).  % first name, last name, age

人を何か他のものと関連付けたい場合、人の鍵が本当に必要です。したがって、私は人を次のように主張する傾向があるかもしれません:

person(id(_), ...).  % Maintain id as a uniq person key; or done implicitly as above

もちろん、今は Prolog アサーションをリレーショナル データベース テーブル エントリのように見せています。そして、私は間違ったアプローチを取り、事実の表現を過度に複雑にしているのではないかと思います.

本当に、私の質問は次のとおりです。Prolog で中規模から複雑なデータを管理する際に考慮すべきベスト プラクティスはありますか? 命名規則はその小さな側面です。Prolog の assert/retract のような部分が非効率的であることを読みました。したがって、外部 SQL データベースと Prolog のみの表現に頼る場合など、データ編成自体にどのようにアプローチするかについても疑問に思っています。

補遺

リレーショナル データベースで行われているように、レコードにキーを使用することは、リレーショナル データベースがそれらを使用するまさにその理由から望ましいと思います。つまり、キーを維持する必要があります。ケースごとに Prolog でこれを手動で (明示的に) 行うのは面倒なようですが、一般的にはどのように行われますか? それとも私の仮定は正しいですか？

4

6 に答える 6

6

assert/retract を使用する際の効率に関するあなたの質問にはまだ誰も答えていません。

SWI-Prolog の場合、一言で言えば、ファクトにはインデックスが付けられ (ジャスト イン タイムとは、最初にクエリが実行されたときを意味します)、ルックアップは非常に効率的です (ハッシュ テーブルに基づく)。デフォルトでは、インデックスは最初の引数にのみ適用されますが、これを回避するための組み込み機能があります (すべてを正規化された形式に保つのは面倒だと思います)。

経験則は、すべてのデータがメモリに収まり、頻繁にアサート/リトラクトしない限り、それが最良の選択であるようです。library(persistency) を使用して、述語を永続化できます。

制約やトリガーなどについては、独自の述語を作成する必要があると思いますが、Prolog の構文を使用すると、これらを SQL で定義するよりも冗長になることはありません (リレーショナル データベースでの私の経験はかなり限られているため、話している可能性があります)。私のお尻のうち）。

于 2013-06-09T17:02:54.483 に答える
3

Prolog はリレーショナルデータ モデルに基づいています。

その場合、リレーショナル データ モデルは、平凡に Prolog に適していますが、個人的には、SQL DML で得られるメタデータ機能が恋しいです。ドキュメンテーション - 利用可能な場合 - 簡単に同期が取れなくなる可能性があり、多くの列との関係を処理するのは面倒です。これは、Prolog が型を持たないことと、列を (簡単に) 「名前で呼び出す」ことができないためです - Prolog は「射影演算子」を見逃しています' 関係代数 (そしてもちろん SQL) で利用できます。SWI-Prolog にはこの問題を解決するための library( record ) がありますが、私はあまり好きではありません。

一般に、深くネストされた (XML/HTML/SVG などの) 表現や、空間的および地理的 DB などの次元的にインデックス付けされたエンティティ、または今日のオントロジーによって要求されるような大規模なグラフなど、「実世界」のデータ モデリングに関しては、リレーショナルデータ モデリングだけでは不十分な場合があります。

不足している詳細を提供する必要がありますが、これは技術的に非常に複雑になる可能性があります。Prolog エンジンが提供しない索引付けが必要な場合、低レベル言語 (通常は C) で難しいインターフェースを作成することに没頭することになります。それでは、その複雑なデータをモデルにした、すぐに使用できる (およびデバッグ済みの) ライブラリを備えた、より簡単な言語を使用してみませんか? それらはたくさんあります。

結果として、SWI-Prolog は、Prolog アプリケーションの当初の焦点であった抽象言語 (自然言語と合成言語の両方) の研究ではなく、実用性によって開発が推進されるようになり、たとえば Web やオントロジー用の特殊なインターフェイスを備えています。パッケージのページを参照してください。それらのほとんどは、複雑なデータへの巧妙に作成されたインターフェイスです。

ソフトウェア エンジニアリングの観点からは、このようなインターフェイスを使用できるかどうかによって、言語の選択が異なります。SWI-Prolog の評判がいかに高いかを強調するために、最近 (Python と同様に)オランダの ICT イノベーション アワードにノミネートされました。

DCG ベースの HTML 生成に JavaScript を埋め込むための準引用のような進行中の開発と、SWI-Prolog メーリング リストからの優れたサポートは、大きな付加価値です。

個人的には、実践的なタスクに適用することでRDFモデリングを学ぶことに力を注いでいます。

于 2013-06-09T07:38:37.323 に答える
0

WordNet の Prolog バージョンをダウンロードして、そこで何が起こっているかを見てみましょう。

  • リレーショナル データベース テーブルとは別のファイルです。
  • 必要に応じて、整数 ID を生成し、最初の位置に配置します。WordNet は、言葉の感覚に独自の ID を与えることのみを選択しました。
  • ドキュメントの各位置に何が入るかを文書化します。

ここでの他の提案は、私にとって不必要に負担に思えます。Prolog だけがこのデータにアクセスすることに満足している場合は、Prolog の形式で保存し、Prolog を使用している間、生活を楽にしてください。Prolog がデータにアクセスするいくつかの言語の 1 つにすぎない場合は、リレーショナル データベースに貼り付けてください。Prolog からそれに到達する負担は、他のすべてがより簡単になることで相殺されます。

Prolog を使用して移行を偽造することはそれほど難しくありません。活用するlisting/1:

%   save_database(+functor, +filename)
%
% Records all the facts of Functor in Filename
save_database(Functor, Filename) :-
  telling(OldStream), tell(Filename),
  listing(Functor),
  told, tell(OldStream).

例：save_database(foo/1, 'foo.pl').この上にデータ移行を簡単に書くことができます。他の回答で提案されているより複雑なものを正当化するユースケースは本当にありません。

于 2013-06-09T04:16:06.620 に答える