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

Hi Christoffel,

> Most KR systems indeed offer the option to query for both, 
> but I must say I always assumed a SPARQL query would support 
> transitive closure, hence would return the logical result 
> instead of only directly asserted results. 

I'd like to be sure what you mean here, because I've got a category
error on the way you have expressed it.  I'm assuming you mean that
SPARQL should allow a query to express a query on the transitive closure
of a property.

> If both are required, the graph could solve it, but why not 
> add the option in the query instead of having to query 2 
> graphs. A direct result might be requested as SELECT DIRECT 
> ?x ?y And the logical result might be requested as SELECT ALL ?x ?y

I don't *know* why DAWG have not included this functionality.  It could
be that many SPARQL implementations are expected to be built over SQL
databases which do not directly support the computation of transitive
closure.

But I don't think "why not" is the right question.  I think "Why" is the
right question, where the question should be grounded in existing SWBP
work.  The requisite functionality is supportable.  I tend to agree that
it might be nice to be able to express the query directly in SPARQL but
I'm not sure what the implementation cost would be and I'm pretty sure
DAWG will have considerd this.

What we are working up to here is a comment to DAWG.  Roughly we might
say one of:

  1. nothing
  2. we think it would be desirable, but not essential to express
t.closure in SPARQL
  3. we think it is essential to express t.closure in SPARQL.

To 2 we might add that we if they choose not to support it, then there
might be some best practices on handling transitive properties as a
result.

> 
> 
> Which one should be default is debatable, but it seems to me 
> that a lot of applications may only be interested in the 
> logical result of the query. The option to query only direct 
> is also very valuable to browse the graph (or parts of it), 
> which can be used, amongst other things, in DS-systems, or 
> search-engines (refine query).
> 
> Adding a second Closure equivalent of the property would only 
> make querying more complicated, unless a standard to do this 
> is defined.

I guess I was suggesting that a best practice, rather than a standard,
might be desirable.

Brian

> 
> 
> 
> 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: public-swbp-wg-request@w3.org 
> [mailto:public-swbp-wg-request@w3.org] On Behalf Of Christopher Welty
> Sent: maandag 5 december 2005 2:20
> To: McBride, Brian
> Cc: public-swbp-wg@w3.org; public-swbp-wg-request@w3.org
> Subject: Re: [SKOS, SPARQL, ALL] Closure and SPARQL
> 
> 
> Yes, every KR system I've ever used provided an API for 
> getting "asserted" 
> vs. "inferred" information.  Logically they are equivalent.
> 
> -Chris
> 
> Dr. Christopher A. Welty, Knowledge Structures Group IBM 
> Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532
> Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
> Email: welty@watson.ibm.com
> Web: http://www.research.ibm.com/people/w/welty/
> 
> 
> 
> "McBride, Brian" <brian.mcbride@hp.com> Sent by: 
> public-swbp-wg-request@w3.org
> 12/03/2005 04:16 PM
> 
> To
> <public-swbp-wg@w3.org>
> cc
> 
> Subject
> [SKOS, SPARQL, ALL] Closure and SPARQL
> 
> 
> 
> 
> 
> 
> 
> I have been reviewing SPARQL last call WD on the plane as 
> promised, and wanted to return to an issue that David Wood 
> had previously raised.  (No URLs available at 30k feet - sorry)
> 
> SPARQL does not support the expression of property closures, e.g.
> transitive closure.
> 
> To ground this in BP work, consider an RDF graph that 
> includes dc:subject properties whose values come from a SKOS 
> taxonomy.  You cannot express directly in SPARQL a query to 
> find all the resources whose dc:subject is a (possibly 
> indirect) narrower term of some term T.
> 
> I earlier suggested that SPARQL does not have to support 
> transitive closure because the graph can do it.  There can be 
> an inferencing graph which computes the transitive closure of 
> skos:narrower.  If you query that graph you query the 
> transitive closure relationship.  If you query the ground 
> graph you get the direct, well at least directly asserted, 
> relationship.  The question arises, whether there is a need 
> to distinguish between the direct relationship and the 
> closure relationship.  Are these different properties.  
> Should we define skos:inNarrowerClosure (or something more 
> appealingly named).
> 
> In terms of the plumbing, this is not necessary.  SPARQL 
> supports querying over multiple graphs and so can support 
> querying the ground graph to get at the direct relationship 
> and an inferred graph to get at the closed one.
> 
> However it strikes me that the direct relationship and the 
> closure are different relationships and it might be best 
> practice, perhaps generally, perhaps under certain 
> circumstances, to define both.  I believe the distinction to 
> be useful.  If I am creating a graphical representation of a 
> SKOs taxaonomy, I want to query for the direct relationship.  
> But if I'm searching for relevant resources, I probably want 
> the closure relationship.  If it can be useful to make this 
> distinction, there may be value in defining property to 
> relate the direct property to its closure property, e.g. 
> ex;isTransitiveClosureOf.
> 
> I'm feeling a bit out of my depth here.  I expect this all 
> got worked out a while ago, but just thought I'd check.
> 
> Brian
> 
> 
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.11/191 - Release 
> Date: 2/12/2005
>  
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.12/193 - Release 
> Date: 6/12/2005
>  
>

Received on Thursday, 8 December 2005 00:29:17 UTC