W3C home > Mailing lists > Public > public-swbp-wg@w3.org > December 2005

Re: [SKOS, SPARQL, ALL] Closure and SPARQL

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Mon, 12 Dec 2005 12:49:33 +0100
Message-Id: <C6197489-3840-4B36-B9C7-37E67EB0776B@inf.unibz.it>
Cc: "McBride, Brian" <brian.mcbride@hp.com>, "David Wood" <dwood@softwarememetics.com>, "Pat Hayes" <phayes@ihmc.us>, "Christopher Welty" <welty@us.ibm.com>, <public-swbp-wg@w3.org>
To: Christoffel Dhaen <christoffel@landcglobal.com>

On 12 Dec 2005, at 11:49, Christoffel Dhaen wrote:
> Thatís all. RDF is a graph, it has native transitive properties.  
> Being able to express in query that only the direct nodes should be  
> taken into account, or that the transitive nature of the properties  
> has to be taken into account is a logical step. No more, no less.

At this point it is not clear to me anymore what you want :-)

1) if you want, e.g., to ask for the "descendant" property if you  
have only the "child" property in the graph, then you need the  
abiltiy to express the transitive closure of a property in the query  
language. This has a cost, and current SPARQL does not handle this.

2) if you want to distinguish in a query between "stated" transitive  
properties from "derived" transitive properties, then you need a  
different mechanism. This would be the case of existing transitive  
properties in RDFS; e.g., subClass: if there is a graph "(a subClass  
b)(b subClass c)" whenever you ask for "(X subClass c)" you want to  
get the answer "X=b" as being somehow directly stated as opposed to  
the answer "X=a" as being somehow derived. This distinction is  
possible according to the latest discussions in the DAWG: if you make  
the query "(X subClass c)" by requiring only "simple RDf entailment"  
you get the answer set {X=b}, while if you require "RDF entailment"  
you get the answer set {X=b, X=a}. "simple RDf entailment" and "RDf  
entailment" are defined in the RDF MT semantics W3C document.

Does this characterise your request?

cheers
--e.
Received on Monday, 12 December 2005 11:49:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:15 UTC