7

このブログ記事Problems of the RDF model: Blank Nodesを読みましたが、空白ノードを使用するとデータの処理が複雑になる可能性があると言及されていました。

空白ノードを使用すると SPARQL クエリを実行するのが難しい理由の例を教えてください。空白ノードの複雑さがわかりません。存在変数の意味とセマンティクスを説明してもらえますか? RDF Semantics Recommendation 1.5に記載されているこの説明がよくわかりません。存在変数としての空白ノード。

4

1 に答える 1

14

存在変数

(一階の) 述語計算では、実際に話しているドメイン内の特定の個人を言わずに (または、おそらく知ることなく)、存在するものについて主張できるようにする存在量化があります。たとえば、次のような文

hasUserId(JoshuaTaylor,1281433)

文を伴う

∃ x .hasUserId( x ,1281433)

もちろん、最初の文が真でなくても 2 番目の文が真であるシナリオはたくさんあります。その意味で、2 番目の文は最初の文よりも情報が少なくなります。また、2 番目の文の変数xは、談話のドメイン内のどの要素が実際に指定された userId を持っているかを見つける方法を提供しないことに注意することも重要です。また、指定されたユーザー ID を持つものは1 つだけであると主張することもありません。より明確にするために、次の例を使用できます。

∃ y .hasAge(y,29)

誰かまたは何かが 29 歳であるため、これはおそらく真実です。ただし、 yを 29 歳の個人として話すことはできないことに注意してください。この文からわかることは、少なくとも 1 つあるということだけです。

2 つの文で異なる変数を使用しましたが、指定されたプロパティを持つ個体が同じではない可能性があることは言うまでもありません。これは、ネストされた定量化で特に重要です。

∃ x .∃ y .likes( x , y )

この文は、ドメイン内に自分自身が好きな個人が 1 人いるため、真である可能性があります。xとyが文中で異なる名前を持っているからといって、それらが同じ個人を指していない可能性があるという意味ではありません。

存在変数としての空白ノード

RDF Semanticsで定義された定義済みの RDF 含意モデルがあります。これについては、別の Stack Overflow の質問であるRDF Graph Entailmentで詳しく説明されています。アイデアは、RDF グラフが、グラフで言及されている空白ノードに対する大きな存在量化として扱われるというものです。たとえば、グラフ内のトリプルが t 1、…、t nであり、それらのトリプルに現れる空白ノードが b 1、…、b mである場合、グラフは次の式になります。

∃b 1 , …, b m .(t 1 ∧ … ∧ t n )

上記の存在変数の説明に基づいて、これはデータ内の空白ノードがドメインの同じ要素または異なる要素を参照する可能性があることを意味し、1 つの要素が空白ノードの代わりになる必要はないことに注意してください。 . これは、空白のノードを含むグラフをこのように解釈すると、予想よりもはるかに少ない情報しか提供されないことを意味します。

実データの空白ノード

さて、上記の議論は、人々が空白ノードを存在変数として使用している場合に役立ちます。多くの場合、著者はそれらを匿名ではあるが明確で明確なオブジェクトと考えています。たとえば、さりげなく書くと

@prefix : <https://stackoverflow.com/q/20629437/1281433/> .

:Carol :hasAddress [ :hasNumber 4222 ;
                     :hasStreet :Clinton_Way ] .

指定されたプロパティを持つ単一のアドレスがそこにあると言いたいのかもしれませんが、RDF含意モデルによれば、それは私たちがしていることではありません。

実際には、RDF含意は通常使用しないため、これはそれほど問題ではありません。ただし問題は、空の変数のスコープがグラフに対してローカルであるため、キャロルのアドレスを要求するエンドポイントに対して SPARQL クエリを実行して、再利用できる IRI を取得できないことです。次のようなクエリを実行すると:

prefix : <https://stackoverflow.com/q/20629437/1281433/>

construct {
  :Mike :hasAddress ?address
}
where {
  :Carol :hasAddress ?address
}

結果として、次の (役に立たない) グラフが返されます。

@prefix :      <https://stackoverflow.com/q/20629437/1281433/> .

:Mike   :hasAddress  []  .

空のノードしかないため、住所に関する詳細情報を取得する方法はありません。IRI を使用した場合、たとえば、

@prefix : <https://stackoverflow.com/q/20629437/1281433/> .

:Carol :hasAddress :address1267389 .
:address1267389 :hasNumber 4222 ;
                :hasStreet :Clinton_Way .

その場合、クエリはより役立つものを生成します。

@prefix :      <https://stackoverflow.com/q/20629437/1281433/> .

:Mike   :hasAddress  :address1267389 .

なぜこれがより便利なのですか？最初のケースは、データを持っているようなものです

∃ x.(hasAddress(Carol,x) ∧ hasNumber(x,4222) ∧ hasStreet(x,ClintonWay))

結果を返す

∃ y.hasAddress(マイク,y)

確かに、マイクとキャロルが同じ住所を持っている可能性はありますが、これらの文からは確実に知る方法はありません. 次のようなデータがあると、はるかに役立ちます

hasAddress(Carol,address1267389)
hasNumber(address1267389,4222)
hasStreet(address1267389,ClintonWay))

結果を返す

hasAddress(マイク、アドレス 1267389)

このことから、住所が同じであることがわかり、それについて尋ねることができます。

結論

これがデータとその消費者にどの程度影響するかは、典型的なユース ケースが何であるかによって異なります。自動的に作成されたグラフの場合、後で参照できるようにする必要があるデータの種類を事前に知るのは難しい場合があるため、できるだけ多くのリソースに対して IRI を生成することをお勧めします。IRI は自由形式なので、通常、これを行うのはそれほど難しくありません。たとえば、適切な「ベース」IRI がある場合、たとえば、

http://example.org/myData/

その後、リソースを識別するサフィックスを簡単に追加できます。例えば、

http://example.org/myData/addresses/addr1
http://example.org/myData/addresses/addr2
http://example.org/myData/addresses/addr3
http://example.org/myData/individuals/ind34
http://example.org/myData/individuals/ind35
于 2013-12-17T14:42:46.553 に答える