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

Hi,

Just wondering is this has been formally rejected, or if this is still under discussion. 

Regards,
   Christoffel

PS: Happy New Year.

 

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: public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]
> On Behalf Of Christoffel Dhaen
> Sent: dinsdag 13 december 2005 15:44
> To: Pat Hayes
> Cc: public-swbp-wg@w3.org
> Subject: RE: [SKOS, SPARQL, ALL] Closure and SPARQL
> 
> 
> Actually, I brought this up because I thought that the D-Entailment
> mentioned in the SPARQL specs only covered Literals and was introduced
> after the whole XMLLiteral type-checking discussion, hence did not cover
> the subPropertyOf and subClassOf.
> I thought I had misread the specs after hearing that it was covered, but
> it seems like it isn't after all.
> 
> Anyway, as RDFS entailment takes the domain-range into account, that's not
> what I intended.
> Perhaps looking at the structure as a graph is indeed a key thing here: as
> long as you can walk a path (like the subClassOf), you can reach a node.
> You don't "add" anything to the graph, because the information can be
> reached by following the path.
> 
> In short: there is a hierarchy that should be taken into account in the
> queries. If not, even with normal relational databases the need for
> hierarchical queries popped up, and since no standard was in place to
> express this, each implementation has its own syntax. I'm more than
> convinced that the need to express this in SPARQL will arise (because of
> subPropertyOf and subClassOf).
> 
> And this is not supported by the query language, but left to the graph,
> and that is my main concern.
> In other words, not supported by a query language that is developed to
> query something with a hierarchy.
> It's saying: "leave it to the database, there is no need for hierarchical
> queries. If they need the hierarchy, they should query a different
> database". And that didn't work out for normal relational databases.
> 
> RDFS entailment would "add" edges to the graph, this doesn't. It only uses
> the hierarchy. The hierarchy is there "by nature", why not use it?
> 
> 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: Pat Hayes [mailto:phayes@ihmc.us]
> > Sent: maandag 12 december 2005 19:35
> > To: Christoffel Dhaen
> > Cc: public-swbp-wg@w3.org
> > Subject: 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
> >
> >
> > --
> > 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/198 - Release Date:
> 12/12/2005
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date:
> 12/12/2005
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 4/01/2006

Received on Thursday, 5 January 2006 13:12:22 UTC