本体限制对 SPARQL 最终结果的影响

Posted 2023-02-24

【中文标题】本体限制对 SPARQL 最终结果的影响

【英文标题】：Consequence of restrictions in ontology on SPARQL end results

【发布时间】：2015-08-17 14:11:10

【问题描述】：

我关心我的本体（dgo.owl）的两个类（SensingDevice 和 Property），如下图所示。这两个类通过 observes 属性连接：

相关本体部分如下：

<owl:Class rdf:about="http://www.iiitd.edu.in/~haroonr/ontologies/DGO#TemperatureSensor_Livingroom">
  <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#observes"/>
      <owl:allValuesFrom rdf:resource="http://purl.oclc.org/NET/ssnx/qu/dim#Temperature"/>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

现在，使用 SPARQL 查询，我想知道 TemperatureSensor_Livingroom 类观察到的属性，它是 SensingDevice 的子类。同样，我正在使用以下查询：

SELECT ?y 
WHERE 
    dgo:TemperatureSensor_Livingroom rdfs:subClassOf  ?p .
    ?p owl:allValuesFrom ?y .

通过此查询，我确实获得了所需的结果，但我不明白如果不使用 observes 属性，我将如何获得结果？我尝试使用 observes 属性来制定不同的查询，但它们都没有产生所需的答案。我认为在这种情况下，我会通过一些技巧获得结果，但我想知道这种情况下的正确查询。我可能是错的，但我认为限制在后台做一些我无法得到的事情。这些限制会影响我们查询的方式吗？

更新： 从 Artemis 和 Chris 的回答中，我发现在这种情况下，没有充分的理由直接在 SPARQL 查询中使用 observes 属性，因为上述答案中提供了正当理由。有了这个，我发现了另一个相关的用例：

本体是相同的（dgo.owl），只是我添加了一些如上所述的类。现在，如果我查询与上一个案例中提到的相同的东西，即

SELECT ?y 
WHERE 
dgo:TemperatureSensor_Livingroom rdfs:subClassOf  ?p .
?p owl:allValuesFrom ?y .

正如预测的那样，它产生的输出为：

----------------------------------------------------------
| x | y                                                  |
==========================================================
|   | dgo:PhysicalInput                                  |
|   | <http://purl.oclc.org/NET/ssnx/qu/dim#Temperature> 

换句话说，它产生与两个属性相关的输出，即observes和detects。在这种情况下，我如何才能获得仅与 observes 属性相关的输出。

【问题讨论】：

您不应该更改您的问题，而是发布另一个问题。这有点令人困惑，因为将来会考虑这些问题的人。此外，如果您这样做，您需要更新问题所附的资源。

【参考方案1】：

如果您编写以下查询：

SELECT distinct *
WHERE 
    dgo:TemperatureSensor_Livingroom rdfs:subClassOf ?o.
    ?o ?p ?y.

您正在提取与dgo:TemperatureSensor_Livingroom 相关的所有内容，这也是?o 的子类。如果查看?p 列，您可以看到只有observers only temperature 是通过owl:allValuesFrom 连接的。那就是不需要指定类型。

如果您将查询更改为：

prefix dgo: <http://www.iiitd.edu.in/~haroonr/ontologies/DGO#>
SELECT distinct *
WHERE 
    ?s rdfs:subClassOf ?o.
    ?o owl:allValuesFrom ?y.

可以看到又出现了observers only temperature。所以基本上我想说的是，你限制三元组中每个成员的方式会直接影响你在下一阶段提取的内容。希望这会有所帮助！

更新 1： 根据您更新的查询，您只需在查询中命名您的预期对象属性：

prefix dgo: <http://www.iiitd.edu.in/~haroonr/ontologies/DGO#>
prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>
SELECT *
WHERE 
    dgo:TemperatureSensor_Livingroom rdfs:subClassOf  ?p .
    ?p owl:allValuesFrom ?y .
    ?p owl:onProperty ssn:observes

【讨论】：

好的。那么如何解决作为给定问题的更新提到的案例。

【参考方案2】：

那是因为您正在查询 TBOX，而您的查询中的 ?p 转换为代表匿名类限制的 bnode。您没有绑定到查询中的实例，而是用于owl:allValuesFrom 限制的值/类。所以

http://purl.oclc.org/NET/ssnx/qu/dim#Temperature

将是您查询的结果。如果您想搜索构成匿名类的个人，您将使用observes 属性。查看您的数据，您尚未创建任何使用 observes 的实例，因此显然没有使用它。

【讨论】：

我同意你的观点。但是，在 UPDATE 提到的场景中，如何获得预期的答案。

试试：SELECT ?y WHERE dgo:TemperatureSensor_Livingroom rdfs:subClassOf ?p . ?p owl:onProperty <http://purl.oclc.org/NET/ssnx/ssn#observes>; owl:allValuesFrom ?y .