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

I am getting slightly lost in the discussion.

Let me re-summarize here in a more specific way and see how we all react
to it.

It seems that we are simply asking for two extra predicates to use in
SPARQL queries: ?x directSubClassOf ?y, ?r directSubPropertiesOf ?s

You could form a query with these predicates to walk the chain by
levels, or you could use the original subClassOf/subPropertiesOf which
implies the full closure (This actually is what I believed they meant
within SPARQL. Please correct me if I am wrong).

How dose this sound? Isn't this what we have been talking about? The
above seems very clear what they mean within a query.

I'd suggest to open the discussion of querying "direct" or "asserted" vs
"inferred" graph as a different orthogonal topic. For the reason that
whether something is *directly* connected to another thing (via which
ever property) could actually be inferred. So simply offering the
service to query the original graph possibly isn't going to solve all
cases.

Almost all systems allow you to write some user-defined rules to add
edges during the construction of the "inferred" graph (including adding
subClassOf edges). This means you can have something directly connected
to another thing only in the inferred graph but not even connected by
any means in the original. Thus querying the direct/asserted graph will
not get you *all* the edges you possibly want in those cases.

Gary






-----Original Message-----
From: public-swbp-wg-request@w3.org
[mailto:public-swbp-wg-request@w3.org] On Behalf Of McBride, Brian
Sent: Monday, December 12, 2005 12:11 AM
To: David Wood; Christoffel Dhaen
Cc: Enrico Franconi; Pat Hayes; Christopher Welty; public-swbp-wg@w3.org
Subject: RE: [SKOS, SPARQL, ALL] Closure and SPARQL


Hi David,

> 
> Hi all,
> 
> I like Christoffel's summary below and agree with it. 

I take it you are speaking as a member of the WG rather than as a chair
here.  I note also that you have raised this issue but have not responed
to my other comment on SPARQl concerning DESCRIBE.

It might  be useful background for the WG David, if you would explain
why you feel this issue is important.

I do not agree with supporting Christoffel's position.  His arguments
are based on terms like "it is a bit strange that" and "it would be nice
if" which are rather weak.  He also argues for implementation complexity
of this approach, and I just don't see where this complexity comes from.
I do not understand your reference to "non-standard" mechanisms which
seems like a bit of unwarrented sophistry.  I don't see the argument,
grounded in SWBP work, for introducing an optional element to the
language as this will introduce interoperability issues.

I also found the exert from the Part/Whole draft pointed out by Alistair
illuminating, though unlike Alistair, I didn't find it a bodge, as it
seems intuitive to me that the direct and transitive properties are
different.

I am also not clear what you are asking for here.  Christoffel's message
seems to suggest that he is just asking for RDFS semantics, i.e. the
transitive closure of subPropertyOf and subClassOf.  He also mentions
domain and range.  Your text mentions transitive closure in general, as
opposed to just closure on RDFS properties, but makes no mention of
other inferred triples, e.g. from domain and range constraints, other
Owl constructs, or indeed inferred by any means e.g. rules.  What
exactly do you want and why? 

In short, Christoffel's position reads to me like "I wouldn't do it that
way", which is fine - I might not do it that way either - but I am
suggesting that the WG should set a higher burden on itself before
commenting on the work of other working groups.  Every comment has a
cost, and we should take care that cost we impose on other WG's is
justified.  It is appropriate for other WGs to say "this gives us a
problem because" or "this violates one of our specs", but I don't think
it is appropriate to duplicate the work of another WG with comments of
the form "I woudn't do it that way".

I suggest that DAWG have enabled us to do everything we think we need to
do using standard mechanisms and thus no comment on this is justified,
and certainly not one that introduces optional functionality.

Brian


 
> Unfortunately, that still leaves us with Brian's question, 
> summarized as, "Should  
> SWBP take a position on SPARQL as it stands?"  I think it should.   
> Further, I think the position should be something like this:
> 
> "The SWBP&D WG has identified areas of interest which would 
> require the querying of transitive closure over RDF graphs 
> and requests that the DAWG note this as a requirement of 
> SPARQL.  The SWBP&D makes no judgement on whether this 
> requirement should be optional or mandatory and leaves that 
> to the DAWG.  However, the SWBP&D would be disappointed to 
> see this requirement fulfilled solely via non- standard mechanisms."
> 
> I don't think that is too strong or overstating our concerns. 
>  It leaves the DAWG to fulfill its charter by itself.  It 
> also provides strong encouragement to plug a significant gap 
> in a manner which will not leave practitioners hanging.
> 
> Thoughts?
> 
> Regards,
> Dave
> 
> 
> On 9 Dec2005, at 06:35, Christoffel Dhaen wrote:
> > I'm not trying to suggest that SPARQL should be more 
> expressive than 
> > the languages it was designed for, I am merely trying to suggest it 
> > should support or be able to express the possibility to 
> query for the 
> > transitive closure of the transitive properties native to the rdf 
> > schema: rdfs:subClassOf and rdfs:subPropertyOf.
> >
> > RDF(s) has some semantics, like rdfs:subClassOf,rdfs:subPropertyOf,
> > rdfs:range and rdfs:domain.
> > These can be used to infer information.
> > As most KR-systems provide a way of retrieving "asserted" and 
> > "inferred" information, it just seems a bit strange that 
> SPARQL has no 
> > notion of the inferred and can only query for the asserted 
> > information, unless you have an "asserted" graph and an "inferred"
> > graph stored seper.
> >
> > I'm not saying all implementations of SPARQL should implement the 
> > inferred option, but it would be very nice if some implementations 
> > would, and have the option to express in the query if the result 
> > should contain only the asserted, or also the inferred.
> > Being able to do so would save a lot of applications a lot 
> of trouble 
> > of having to go though maintaining an asserted version and 
> an inferred 
> > version if they would like to use SPARQL to query it, 
> because it seems 
> > that that is the only option for such an application if 
> they want to 
> > use SPARQL and query for the asserted and inferred. And this seems 
> > like a lot of overhead if this has to be done over and over 
> again for 
> > each application that wants to query both. It seems a lot 
> more natural 
> > to have a (or a few) SPARQL implementations that have this 
> option, but 
> > if this can not be expressed in the query, then this would lead to 
> > "customized"
> > parameters for each of those implementations.
> > It's like the /*+RULE*/ option in oracle queries: you can 
> optimize the 
> > queries all you want for oracle, but you'll have to start all over 
> > again if you move to another database.
> > Almost the same thing here: if I would like an implementation that 
> > supports querying for the inferred without having to 
> maintain a second 
> > inferred graph, I would have to create a custom version with custom 
> > keywords in the SPARQL statement.
> > It would be much nicer if there was a standard way to 
> express this in 
> > the query and not a 1001 implementation dependant different 
> options to 
> > express the same. Since SPARQL is designed to query RDF, 
> and RDF has 
> > semantics, it seems like a logical step to include 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: Enrico Franconi [mailto:franconi@inf.unibz.it]
> >> Sent: donderdag 8 december 2005 23:58
> >> To: Christoffel Dhaen
> >> Cc: McBride, Brian; Christopher Welty; public-swbp-wg@w3.org;
> >> public-swbp-
> >> wg-request@w3.org
> >> Subject: Re: [SKOS, SPARQL, ALL] Closure and SPARQL
> >>
> >> On 8 Dec 2005, at 15:09, Christoffel Dhaen wrote:
> >>> As far as I know, RDF does not allow you to state that a 
> property is 
> >>> transitive, but the RDF schema itself has 2 transitive
> >>> properties: rdfs:subClassOf and rdfs:subPropertyOf.
> >>
> >> True: these are fixed properties that are by definition transitive.
> >> But what if you want to ask for a descendant (which is the 
> transitive 
> >> closure of a "child" property) when in the RDF graph yoy have only 
> >> the "child" property (which is not transitive)? This is 
> exacttly the 
> >> classical example calling for a transitive closure operator in the 
> >> query language.
> >>
> >>> I could be horribly wrong here, but one of the use-cases 
> listed is:
> >>> "2.17 Building Ontology Tools (Semantic Web)"
> >>> It says: "Some parts of the ontology editor require the 
> transitive 
> >>> closure of the query and other parts do not."
> >>>
> >>> Imho, a lot of applications will require the transitive 
> closure of 
> >>> the query.
> >>
> >> Perfectly true. The main problem here is that the existence of a 
> >> transitive closure operatore raises the data complexity of 
> the query 
> >> language beyond SQL (it becomes of the same complexity as datalog).
> >>
> >>> I don't think I said that RDF and OWL express transitive closure, 
> >>> but they do express transitivity.
> >>
> >> This does not help. You want the transitive closure of 
> existing non 
> >> transitive properties (see the example of "child").
> >>
> >>> And indeed, the transitive closure of the transitive 
> properties is 
> >>> what I would expect to find in a query language for RDF.
> >>
> >> Sure, but it ain't easy: you need a full fledged "graph" query 
> >> language (see, e.g., [1]), while I guess that SPARQLl suffers of a 
> >> mixed origin: a bit of SQL/relational data model and a bit 
> of graph 
> >> data model.
> >>
> >> cheers
> >> --e.
> >>
> >> [1] C Gutierrez, C Hurtado, AO Mendelzon. Foundations of 
> Semantic Web 
> >> Databases. PODS'04
> >>
> >>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date:  
> >> 7/12/2005
> >>
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.1.371 / Virus Database: 267.13.13/195 - Release Date:  
> > 8/12/2005
> >
> >
> 
>

Received on Monday, 12 December 2005 09:19:28 UTC