大家好，>我之前建议SPARQL不必支持transitive>关闭，因为图形可以完成。可以有一个>推理图>它计算skos的传递闭包：窄。如果您查询>查询传递闭包关系的图形。如果>您的查询>你得到的地面图是直接的，至少是直接断言的，>关系。问题是，是否有必要>区分直接关系和闭包>关系。这些属性不同吗。我们应该定义>skos：在NarrowerClosure（或其他更吸引人的名字）中。只需简单评论一下这种设计模式：>从[1]节“一般问题>传递关系-部分和直接部分”。。。“在许多应用程序中，需要的不是所有部件的列表，而是部件的下一级细分列表，即给定实体的“直接部件”。因此，使用属性层次结构定义hasPart的子属性通常很有用，该子属性不是可传递的，并且只将每个子属性链接到下一个级别。对于这些示例，我们将此子属性称为hasPart_directly。当然，请注意，仅仅是“直接”部分的概念是主观的，人们可以根据许多因素发明中间直接部分，或将其消除。”传递属性的“直接子属性”模式有一个开销，当您希望对这些属性进行细化时，就会出现这种开销。例如，假设我从skos开始：更窄。因为skos:strighter是可传递的，所以我还声明了skos:slighter的一个子属性，称为skos:thatter_direct。现在，让我们假设第三方需要一个是skos:cringer的精化属性，所以他们发明了一个属性，例如：窄物质，并将其声明为skos:cringer的子属性。为了获得直接行为，他们还必须定义一个属性，例如：strightrSubstance_direct，并将其声明为skos:strightr_direct的子属性。最终得到的属性树如下所示：图片：http://isegserv.itd.rl.ac.uk/cvs-public网站/~checkout~/skos/scratchpad/directly.png我不认为这太复杂以至于不可行，但它有点麻烦，而且感觉确实像是一种变通方法。我当然很感激关于如何正确处理这一问题的最佳实践说明，例如通过不同的sparql端点，如果这是最好的方法的话？干杯，铝。[1]http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html
接收日期：2005年12月9日星期五11:32:34 UTC