大家好 rdf/sparql 开发者。这是一个一直困扰我一段时间的问题,但自从 rdf 和 sparql 规范发布以来,似乎没有人准确地回答它。
为了说明这种情况,RDF 定义了几种处理资源多值属性的方法;从创建尽可能多的具有相同 subjet-predicate uris 的三元组到集合或容器。这一切都很好,因为每种模式都有自己的特点。
但从 SPARQL 的角度来看,在我看来,查询这些结构会导致过于复杂的查询(更糟糕的是)无法转录成合理的结果集:您不能使用变量来查询任意长度,而 propertyPath 确实不保持“自然”秩序。
以一种天真的方式,在许多 SELECT 或 ASK 查询中,如果我想查询或过滤容器或列表的值,我大部分时间都不会关心底层模式到底是什么(如果有的话)。例如:
<rdf:Description rdf:about="urn:1">
<rdfs:label>
<rdf:Alt>
<rdf:li xml:lang="fr">Exemple n°1</rdf:li>
<rdf:li xml:lang="en">Example #1</rdf:li>
</rdf:Alt>
</rdfs:label>
<my:release>
<rdf:Seq>
<rdf:li>10.0</rdf:li>
<rdf:li>2.4</rdf:li>
<rdf:li>1.1.2</rdf:li>
<rdf:li>0.9</rdf:li>
</rdf:Seq>
</my:release>
</rdf:Description>
<rdf:Description rdf:about="urn:2">
<rdfs:label xml:lang="en">Example #2</rdfs:label>
</rdf:Description>
显然,我希望这两个资源都能回答查询:
SELECT ?res WHERE { ?res rdfs:label ?label . FILTER ( contains(?label, 'Example'@en) }
我也希望查询:
SELECT ?ver WHERE { <urn:1> my:release ?ver }
以原始顺序返回 rdf:Seq 元素(或任何 rdf:Alt)(对于其他模式,是否保留原始顺序无关紧要,所以为什么不保留它呢?) - 除非明确指定通过 ORDER BY 子句。
当然,有必要保持与旧方法的兼容性,所以也许有可能用新的运算符扩展 propertyPath 语法?
我觉得它会大大简化日常 SPARQL 用例。
这对你有意义吗?此外,你有什么理由不尝试实施这个吗?
编辑更正了示例的 urn:2 rdfs:label 值不正确