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

>Perhaps a modified example from the people 
>ontology might help to explain what I'm trying 
>to say. Suppose we have the following graph:
>
>HasPet subPropertyOf Likes
>Person subClassOf Animal
>Woman subClassOf Person
>OldLady subClassOf Woman
>OldLady HasPet Cat
>Cat subClassOf Animal
>
>A query
>(X subClass Person) AND (X Likes Animal)
>gives the answer
>{X= OldLady}
>
>This takes the class-hierachy into account, as wel as the property hierachy.
>
>Unless I have I missed this somewhere, according 
>to the specifications, the query on this graph 
>would not give this result and the resultset 
>would be empty.

It all depends on what kind of entailment you 
think should be used. If you only check for 
simple entailment, then you will just get matches 
against the triples in the graph and no result. 
If you check for RDF entailment, then you will in 
effect only invoke the RDF closure rules (see 
http://www.w3.org/TR/rdf-mt/#RDFRules), so still 
no result.  If you check for RDFS entailment, 
however, then you will check against the closure 
of the graph with respect to the RDFS closure 
rules (see 
http://www.w3.org/TR/rdf-mt/#RDFSRules) which 
includes the inferences that you are after here. 
But this does have a significant cost.

>I would say "simple RDf entailment" and "RDF 
>entailment" entailment as you point out in 2) 
>should be possible on the same graph, but I got 
>the impression that this is not possible.

It is possible, but the SPARQL design would be 
simpler if queries could distinguish different 
kinds of entailment closure by treating them as 
notionally different graphs, so that the query 
can distinguish them by using different URIrefs 
to indicate the different entailment strategies. 
This also allows query services to offer 
intermediate kinds of entailment which have no 
'official' name, such as just checking 
transitivity but ignoring such things as domains 
and ranges.

All of these issues are still under discussion, 
and this message reflects only my views.

Pat Hayes

>1) can be resolved by doing a minus between the 
>entailment and the simple entailment results.
>
>Hope this helps,
>    Christoffel
>
>
>
>
>
>This email and its attachment(s) is confidential 
>and intended solely for the use of the 
>individual to whom it is addressed, and not 
>intended to be further distributed without 
>explicit prior approval of the sender. Any views 
>or opinions presented are solely those of the 
>author and do not necessarily represent those of 
>Language & Computing, Inc. unless explicitly 
>indicated. If you are not the intended 
>recipient, be advised that you have received 
>this email in error and that any use, 
>dissemination, forwarding, printing, or copying 
>of this email is strictly prohibited.
>
>
>
>
>
>
>>  -----Original Message-----
>>  From: Enrico Franconi [mailto:franconi@inf.unibz.it]
>>  Sent: maandag 12 december 2005 12:50
>>  To: Christoffel Dhaen
>>  Cc: McBride, Brian; David Wood; Pat Hayes; Christopher Welty; public-swbp-
>>  wg@w3.org
>>  Subject: Re: [SKOS, SPARQL, ALL] Closure and SPARQL
>>
>>  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.
>>
>>  --
>>  No virus found in this incoming message.
>>  Checked by AVG Free Edition.
>>  Version: 7.1.371 / Virus Database: 267.13.13/197 - Release Date: 9/12/2005
>>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.1.371 / Virus Database: 267.13.13/197 - Release Date: 9/12/2005
>


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 12 December 2005 18:34:50 UTC