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

Hi all, 

I realize I should never have mentioned the domain-range, and never should have used "inferred". I understand why Gary, and I imagine a lot of other people, got very confused when I brought this up. This is beyond the scope of the query language since "new" information is "added" to the graph and would require a reasoner or similar mechanism. This was never my intention. 

All I wanted to point out was transitive closure. And has been noted by E.Franconi: " you need a full fledged "graph" query language, while I guess that SPARQLl suffers of a mixed origin: a bit of SQL/relational data model and a bit of graph data model."

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.
The complexity of introducing this: minimal. I only mentioned it because it has some implications, it won't implement itself. I just got the impression that there was a concern that implementing this would be far to complex. It isn't. 
Hierarchical queries do something similar, and their implementations and syntax vary. 
And that’s exactly what I meant by "non-standard": some implementations will add their own keywords to SPARQL to add this feature. Others will opt to define the indirect variant of a transitive property, like ns1:indirectSubclassOf for rdfs:subClassOf, or as has already been suggested, skos:inNarrowerClosure for skos:narrower. Namespaces will vary, keywords will vary, implementations will vary, and interoperability between systems will be lost. It is far from unwarranted.

The /*+RULE*/ example was not a great one, but the comparison to hierarchical queries still holds: For a standard database there was already a need to create hierarchical queries. Rdf has a hierarchy in classes and properties because the property is transitive. There will be a need for hierarchical queries in SPARQL. 

Being able to query for "inherited" asserted conditions of a class, things like that. Query for some conditions, but take the hierarchy of classes and properties into account when doing so. 


That's all I wanted to point out, again, sorry for the "inferred" and the confusion it caused.

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: McBride, Brian [mailto:brian.mcbride@hp.com]
> Sent: maandag 12 december 2005 9:11
> 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
> > >
> > >
> >
> >
> 
> --
> 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

Received on Monday, 12 December 2005 10:49:58 UTC