- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 21 Aug 2008 14:23:18 -0400
- 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
>
> 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
>
>
>
>
>
I mean ARQ and not ARC re. HP and OpenLink related SPARQL
collaboration. You think SPARQL uniformity has issues, how about ARQ
and ARC :-)
--
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:24:08 UTC