Re: Role of SPARQL

I suspect that Eric was reacting to my previous message (presuming it went
through; I got a message from the W3C that it wouldn't be delivered until I
gave permission for it to be posted, which I did, but I don't *really* know
if it was posted), where I really was talking about "defined as SPARQL".
One of the issues I have with a new language is that we have to be very
specific in defining exactly what everything means. This might seem simple,
but for example, suppose we have a shape definition that says that
something must have exactly two values from some class for some field.  If
in the data, we have two values, but they are owl:sameAs one another, does
that count?  If we have three values, but two of them are owl:sameAs one
another, does that count?  What if one of them is a member of a subclass
instead of the specified class?  Or what if it could be inferred to be a
member via some restriction, etc.?  What seemed like a simple concept
("exactly two") has a lot of variation of possible meaning.  It will be our
job to define that (and more to the point, also the job of anyone who wants
to extend the language).

I was indeed suggesting that we use SPARQL to *define* this.  So that
"exactly two"  would be defined e.g., as   SELECT (COUNT (?r) AS ?many)
WHERE {?object  ?property ?r} HAVING (?many = 2)  This query (with some
statement about the inference behind it - none, RDFS-only, OWL-only
(profile DL, EL, QL, or RL)) makes the answer to all those questions
clear.  And all these pieces (SPARQL, RDFS, OWL) already exist and have
stable semantics.

FWIW, OWL would be superior to SPARQL for this job in some ways, not least
of which you can prove statements in OWL much more easily than you can
prove statements about SPARQL.  I don't think anyone is proposing that we
use OWL in this way, since it has many shortcomings as well (I happen to
think that ICV does a good job of getting the best of both worlds here).


On Tue, Nov 25, 2014 at 9:13 AM, Holger Knublauch <>

> On 11/24/14, 10:59 PM, Eric Prud'hommeaux wrote:
>> Note that there is a leap between "compiles to SPARQL" and "defined as
>> SPARQL queries". The former is a pragmatic way to make your schema useful
>> on more infrastructure; the latter is a question of how implementors,
>> researchers, optimizers etc. will be able to understand and work with the
>> definition.
> Absolutely. Compiling to SPARQL is what I meant only. There can be any
> number of surface syntaxes that produce SPARQL.
> Holger

Received on Tuesday, 25 November 2014 00:07:29 UTC