- From: Axel Polleres <axel.polleres@deri.org>
- Date: Thu, 21 Aug 2008 18:55:11 +0100
- To: Adrian Walker <adriandwalker@gmail.com>
- CC: public-sparql-dev@w3.org, public-lod@w3.org
Hi Adrian, 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). I am well aware of this hiding away of negation as failure / set difference, but well by OPTIONAL it sneaked back in, and as I tried to demonstrate, even without FILTERs. > 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. Expecting consistency on the Web is IMO anyway aa too brave assumption... and likewise is applying a classical explosive semantics to web data. so... what? :-) > 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. You might be interested in our proposal about RDF revocation in that context, BTW, see [1,2] > 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. Clark's completion is, only one way to deal with non-mon, I would be curious to explore that more, actually it might fit to the ongoing discussions of adding to RIF dialects supporting NAF. > 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. Aggregation is tricky for Bnodes already, which wouldn't be the problem in SQL. Anyway, my point is: SPARQL has non-mon, and - as it is there - people will and IMO should use it. You have to know what you are doing, but well. My personal opinion is: Nonmon queries on closed datasets or negation over closed graphs are totally fine. That was also called "scoped negation" by some people and I tried to give it a more formal definition some while ago [3] cheers, Axel 1.Christian Morbidoni, Axel Polleres, and Giovanni Tummarello. Who the FOAF knows Alice? RDF Revocation in DBin 2.0. In 4th Italian Semantic Web Workshop SEMANTIC WEB APPLICATIONS AND PERSPECTIVES (SWAP), Bari, Italy, December 2007. http://www.polleres.net/publications/morb-etal-2007b.pdf 2. Semantic Web Pipes. Christian Morbidoni, Axel Polleres, Giovanni Tummarello, Danh Le Phuoc. Tech. Report, DERI-TR-2007-11-07, DERI Galway, 2007. http://www.deri.ie/fileadmin/documents/DERI-TR-2007-11-07.pdf 3. Axel Polleres, Cristina Feier, and Andreas Harth. Rules with contextually scoped negation. In Proceedings of the 3rd European Semantic Web Conference (ESWC2006), volume 4011 of Lecture Notes in Computer Science, Budva, Montenegro, June 2006. Springer. http://www.polleres.net/publications/poll-etal-2006b.pdf > Hope this helps. > > -- Adrian > > > [1] http://www.doc.ic.ac.uk/~klc/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> > 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>> 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> or > 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> 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. > > -- Dr. Axel Polleres, Digital Enterprise Research Institute (DERI) email: 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.
Received on Thursday, 21 August 2008 17:55:55 UTC