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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> 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: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
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
