エージェント、相互作用、SPARQLおよびパフォーマンス

サイトSHCHERBAK.NETの投稿に関する最新のコメントで取り上げられたトピックの続きです！

親愛なる読者の皆さん、正直に言って、これらのすべてのクエリ言語（SPARQL、SPARULなど）が私を完全に圧迫している-私は現在のプロジェクトと他のセマンティックWebアプリケーションとの互換性レベルを高めるために彼らと協力し始めただけですsparqlアクセスポイントが必要です。

さらに、私はこのプロセスを制御するという事実にもかかわらず、オントロジー分析アルゴリズムの複雑さのほぼ線形の増加を達成しました-sparqlなどは-これらは論理計算です（その複雑さは指数関数的に増加する可能性があります）-タスクはまったく必要ありません-たとえば、サイトでのユーザー作業の統計情報をトリプルストアに（マッピングを介しても）投げるのはなぜですか？ リレーショナルデータベースがより適切に処理できる場合。 そして、あなたはこれでスマートなリクエストを作成できます！ だから何。 それでも優れた特別な分析ツールがあります。

セマンティックWebが得意なので、情報ソースの分布と不均一性を維持します。 繰り返しになりますが、必ずしもRDFまたはOWLへの完全な移行によるものではありません。 セマンティックWebの動的コンポーネント-セマンティックWebサービスを通じて。 ここでのタスクは、SPARQLを介したアクセスをサポートすることです。 しかし、これは維持する必要のある最小限のものです。 また、情報のソース（リポジトリ）がRDFとOWLにある必要はまったくないため、OWLでマッピングを行うために必要なのはイエスですが、どのタスクに対してマッピングをサポートする必要がありますか？着信の未知のコンテンツの条件で外部の影響に適切に対応できるようにするためにリクエストとこれ以上！

システム開発者として、従来のSQLでクエリを記述できる場合、たとえばJenaを介して再帰クエリをフェンスし、クラスのインスタンスを選択すると、数倍（または数十倍）速くなります。 あなたはデータスキームを知っています！ 外部ユーザーまたはエージェントがスキームを知らないと仮定します（したがって、私たちは彼とアクセスポイントを提供します）。 私は繰り返します、あなたはスキームを知っています。 なぜ論理的な結論を下すのですか？ これは効果的ではありません。 または、選択できませんか？ 論理的な結論は、本当に必要な場所で行わなければなりません。

私の観察によれば、現代のトリプレットの開発者でさえ論理的な結論を実装しようとしますが、その速度はリレーショナル計算に匹敵しますが、この論理的な結論がグローバルに必要ではないタスクでも！ そして、複雑さの点で、分析クエリに匹敵する真の結論を出す必要があるとき-誰もが手を振る-それは、計算上困難です。

千リンク以上のオントロジーの「手持ち」リクエストを作成することについて彼らが私に言うとき、私はただ笑った。 これは、少なくとも半分の接続の意味を考慮に入れた結論を引き出すためにあなたの心が持たなければならないものです。 さて、100の接続を使用すると、はるかに簡単になります。 もしそうなら、あなたは状況分析のグランドマスターです（チェスプレイヤーはリラックスして、傍観者を緊張させます）そして、エージェントについて話すとき、彼は「理解」するために環境を調べることができなければなりません。 これはなぜですか？ 調査対象のソースに何らかのアクションを実装する方法を理解します。 これがSPARQLがあなたを助け始めるところです。 ここにのみ問題があります-アクションのロジックを彼（エージェント）に説明する必要があり、それによって彼はそれを理解して聞くことができます。 そして、これは純粋なプログラミングです-さらに、アクションのプログラミングです。 そしてこれは事実やオブジェクトの単なる説明ではなく、すでにもっと複雑なものです...そして私を信じてください。これは多くの人に思われるほど単純な問題ではありません！ ここから、ひどい言葉である人工知能が始まります。

PSもちろん、今では誰もがブームなどのSWアプリケーションを書き始めていることを理解しています。 SWテクノロジーを適用する場所と適用しない場所を同じように考える必要があります。