W3C home > Mailing lists > Public > public-lod@w3.org > August 2008

Re: soliciting your favorite (public) SPARQL queries!

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 21 Aug 2008 14:20:54 -0400
Message-ID: <48ADB206.1080708@openlinksw.com>
To: Adrian Walker <adriandwalker@gmail.com>
CC: axel.polleres@deri.org, public-sparql-dev@w3.org, public-lod@w3.org

Adrian Walker wrote:
> Hi Kingsley --
>
> You wrote...
>
> Re. SPARQL & Aggregates, see: 
> http://esw.w3.org/topic/SPARQL/Extensions/Aggregates
>
> Yes, that shows that some folks are thinking about the issues.
>
> But the fundamental problem is (as stated at the foot of that page) 
> that different implementations of SPARQL aggregates are going ahead 
> without any spec saying /*what */should be computed.  This is the sad 
> SQL history repeating itself, except it's going to be worse with 
> on-the-fly linked RDF data than it was for SQL-with-known-data-tables.
>
>                           Cheers,   -- Adrian
Adrian,

The Wiki post is kinda old.

Take SPARUL and SPARQL-BI as the models going forward. OpenLink 
(Virtuoso) and HP (ARC) have worked hand in hand re. these enhancements, 
and the collaboration will not be stopping anytime soon :-)




Kingsley
>
> Internet Business Logic
> A Wiki and SOA Endpoint for Executable Open Vocabulary English over 
> SQL and RDF
> Online at www.reengineeringllc.com 
> <http://www.reengineeringllc.com>    Shared use is free
>
> Adrian Walker
> Reengineering                    

>         
>
>
> On Thu, Aug 21, 2008 at 1:47 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     Adrian Walker wrote:
>
>         Hi Axel --
>
>         Good to see some thinking about fundamentals.  
>         The omission of negation from the SPARQL spec (and hence the
>         need for your ingenious workarounds) seems to be based on a
>         confusion that can perhaps be explained away like this....
>
>         What some semantic web folks seem to want is that when new
>         facts are added, old conclusions don't go away.  They want
>         things to be monotonic, and they therefore deprecate SQL-style
>         negation-as-failure (NAF).
>
>         Now suppose an old conclusion p depends on ~r  in a consistent
>         theory, and that an update r is pending.
>
>         We could just add r.  p would still hold, but the new theory
>         has both r and ~r.  It's inconsistent.  That means  that a
>         naive theorem prover can prove  absolutely anything from it.
>          A better theorem prover would probably refuse to compute with
>         it.  Neither is a desirable outcome.
>
>         But wait.  In most practical circumstances, adding r is a way
>         of saying that ~r should be removed.  So, take the update to
>         mean "add r and also delete ~r".   The new theory is
>         consistent, and p no longer holds.
>
>         So, the price of keeping consistency through an update is that
>         an old conclusion p may no longer  be entailed.  Under
>         consistent update, using classical logic and using NAF lead to
>         the */same /*behavior.
>
>         If we use Clark's result [1] to view a logic program with NAF
>         as simply shorthand for a set of clauses in classical logic,
>         the above starts to look kind of obvious.
>
>         A similar argument could be advanced for the inclusion of
>         aggregation in an extended SPARQL spec.  Now is perhaps a good
>         time to avoid an error that the SQL folks made -- the results
>         from SQL aggregations are implementation dependent.  That's a
>         bad idea for SQL, and a terrible one for on-the-fly linked
>         data and the Semantic Web.
>
>         Hope this helps.
>
>                                                 -- Adrian
>
>
>         [1]  http://www.doc.ic.ac.uk/~klc/NegAsFailure.pdf
>         <http://www.doc.ic.ac.uk/%7Eklc/NegAsFailure.pdf>
>         <http://www.doc.ic.ac.uk/%7Eklc/NegAsFailure.pdf>
>
>
>         Internet Business Logic
>         A Wiki and SOA Endpoint for Executable Open Vocabulary English
>         over SQL and RDF
>         Online at www.reengineeringllc.com
>         <http://www.reengineeringllc.com>
>         <http://www.reengineeringllc.com>    Shared use is free
>
>         Adrian Walker
>         Reengineering
>
>
>
>         On Thu, Aug 21, 2008 at 11:51 AM, Axel Polleres
>         <axel.polleres@deri.org <mailto:axel.polleres@deri.org>
>         <mailto:axel.polleres@deri.org
>         <mailto:axel.polleres@deri.org>>> wrote:
>
>
>            Tackling the question from the more theoretical side,
>            I like non-monotonic SPARQL queries like the ones modeling set
>            difference.
>
>            E.g.
>            "Give me all persons *without* an email address" in a
>         certain FOAF
>            graph.
>
>
>            i) It is already folklore, that you can do that with using the
>            !bound() filter outside an optional, i.e.
>
>            SELECT ?X
>            FROM G
>            WHERE { ?X a foaf:Person
>                   OPTIONAL { ?X foaf:mbox ?M}
>                   FILTER (! bound(?X) ) }
>
>
>            ii) What some people might find surprising is that I can
>         achieve
>            the same result without using a FILTER, more generally that
>         I can
>            express
>
>            SELECT ?X
>            FROM G
>            FROM NAMED <boundchecker.rdf>
>            WHERE
>             {
>               { ?X a foaf:Person OPTIONAL{ ?X foaf:mbox ?M} }
>               GRAPH <boundchecker.rdf>{ ?M :is :unbound }
>             }
>
>            where <boundchecker.rdf> is the graph containing the single
>         triple
>
>              _:b :is :unbound.
>
>            Maybe requires some thinking, but is a nice example :-)
>
>            (Short explanation: the blanknode in Graph
>         <boundchecker.rdf> only
>            matches to unbound variables from the optional patttern.
>         Note that
>            non-well-designed OPTIONAL patterns are not commutative,
>         see [1].
>            Actually, [1] "kind of" conjectured that non-well-designed
>            patterns are useless, but - as this query shows - they aren't
>            really entirely useless.)
>
>            Axel
>
>            1. http://iswc2006.semanticweb.org/items/Arenas2006bv.pdf
>
>
>            p.s.: Since I didn't see a similar one before, I claim
>         copyright
>            for that one, basically, it is very easily generalizable to
>         model
>            arbitrary queries  SELECT ... P WITHOUT P'
>             ;-)
>
>
>
>            Lee Feigenbaum wrote:
>
>                Hi everyone,
>
>                I'm putting together a "SPARQL by Example" tutorial,
>         which is,
>                as the name suggests, a step-by-step introduction to SPARQL
>                taught almost entirely through complete, runnable
>         SPARQL queries.
>
>                So far, I've gathered a great deal of example queries
>         myself,
>                but I know that many subscribers to these lists
>         probably have
>                favorite queries of their own that you might be willing to
>                share with me.
>
>                I'm looking for:
>
>                1) SPARQL queries
>                2) ...that can be run by anyone (no private data sets)
>                3a)...either by running the query against a public
>         SPARQL endpoint
>                3b)...or by using a public SPARQL endpoint that will fetch
>                HTTP-accessible RDF data (e.g. sparql.org
>         <http://sparql.org> <http://sparql.org>
>                or demo.openlinksw.com <http://demo.openlinksw.com>
>         <http://demo.openlinksw.com>)
>
>                4) ...that answers a real* question
>                5) ...and that is fun!**
>
>                * real is in the eye of the beholder, I imagine, but
>         I'm not
>                looking for  "finds the predicates that relate ex:s and
>         ex:o
>                in this sample RDF graph"
>
>                ** fun is also in the eye of the beholder. fun can be a
>         query
>                on fun data; a clever query that may illustrate a
>         particular
>                SPARQL construct ("trick"); a query that integrates
>                interesting information; a query with surprising
>         results; etc.
>
>                thanks to anyone who is able to contribute!
>                Lee
>
>                PS I plan to make the tutorial slides available online
>         under
>                an appropriate CC license once they are completed.
>
>
>
>            --    Dr. Axel Polleres, Digital Enterprise Research
>         Institute (DERI)
>            email: axel.polleres@deri.org
>         <mailto:axel.polleres@deri.org> <mailto:axel.polleres@deri.org
>         <mailto:axel.polleres@deri.org>>
>
>             url: http://www.polleres.net/
>
>            Everything is possible:
>            rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
>            rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
>            rdf:type rdfs:subPropertyOf rdfs:subClassOf.
>            rdfs:subClassOf rdf:type owl:SymmetricProperty.
>
>
>     Adrian,
>
>     Re. SPARQL & Aggregates, see:
>     http://esw.w3.org/topic/SPARQL/Extensions/Aggregates
>
>
>
>     -- 
>
>
>     Regards,
>
>     Kingsley Idehen       Weblog:
>     http://www.openlinksw.com/blog/~kidehen
>     <http://www.openlinksw.com/blog/%7Ekidehen>
>     President & CEO OpenLink Software     Web: http://www.openlinksw.com
>
>
>
>
>


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Thursday, 21 August 2008 18:21:34 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:17 UTC