Bob MacGregor wrote:
> Dear Bijan,
>
> Thanks for responding. Since I only *outlined* my arguments against SPARQL, it is easy to misinterpret them. I will try to expand on them a bit.
>
> A good query language should has the following attributes (among others):
>
> (1) It should be expressive
> (2) Its operators should be composable, and minimal (except for sugar-coating)
> (3) Its should be pleasantly readable
>
> For the uses we employ in a logic language, we add a couple more:
> (4) It should support aggregation
> (5) It should scale to very large datasets
>
> SQL is an example of a language that meets all of these criteria.
> Datalog satisfies all except that my impression is that it doesn't handle
> aggregation. [...]
Just for the records, I have to object here: Datalog with aggregates is
well-understood, even extensions with recursion and negation have been
defined and implemented [1]
cheers,
axel
1. W. Faber, N. Leone, G. Pfeifer. Recursive aggregates in disjunctive
logic programs: Semantics and complexity. Proc. of the 9th European
Conf. on Art. Intelligence (JELIA 2004). 2004, Springer
> So we have proof of concept.
> I would be happy to use either of these with RDF. Instead, we have SPARQL.
> SPARQL violates all but the last. Violating any of 1, 2, or 3 is grounds for divorce.
>
> Expressivity:
>
> In our RDF applications, we routinely use AND, OR and NOT(UNSAID) operators, with
> arbitrary nesting. Even excluding UNSAID, we can't express our queries in SPARQL, due to the artificial limitations it places on the OR (UNION) operator. We frequently nest AND
> inside of UNSAID, and less often use OR and UNSAID. So, SPARQL doesn't even come close to satifying our expressivity requirements.
>
> Composable Operators:
>
> "Composable" means that operators can be combined to produce useful expressions.
> Only the AND is composable in SPARQL. The UNION operator has artificial syntactic
> restrictions that don't belong. It doesn't have NOT/UNSAID, so composability can't be
> discussed there. Instead of a few composable operators, SPARQL has a kitchen sink
> of non-composable ones.
>
> Pleasantly Readable
>
> Turtle syntax. 'nuff said.
>
> Now I will address a few specific comments:
>
>
>>>I totally fail to see why having *convenience syntax* for expressivity ...
>
>
> I assume you are considering the UNSAID operator to be "convenience syntax".
> If we ignore nested AND/OR/UNSAID within UNSAID, then it is indeed a convenience syntax. That assumes a SPARQL mind-set, which I am not assuming. I believe its not the case that
> OPTIONAL/UNBOUND can simulate UNSAID expressions with compound arguments.
>
>
>>>Even with the qualifier "Almost" I don't believe this is true, and if it happened to be
>>>true, it's not the case that UNA and CWA necessarily help the scale of reasoning.
>
>
> They help if the alternative is using millions of owl:minCardinality and owl:disjointWith statements to accomplish the same thing. No one I know does that, instead they either assume UNA/CWA or they don't use aggregation. Also, they either have millions of owl:maxCardinality statements or they aren't using owl:allValuesFrom.
>
>
>>>RDF and RDFS has neither and Steve Harris has reported a store holding over 1.5 billion
>>>triples and responding in user sufficient real time to various classes of SPARQL queries.
>
>
> My guess is that they aren't computing any aggregate expressions.
>
>
>>>This is a different issue. If you want UNA and CWA it is certainly pragmatically a non-answer
>>>to say,"Hey, you can add it yourself!", at least, IMHO.
>
>
> I'm not sure if you are saying "its OK to add UNA and CWA yourself". If you are, then you are
> abandoning basic precepts of SPARQL and the "semantic layer cake". Plus, you are inventing your
> own semantics. However, WE are adding UNA and CWA ourselves, because we have no choice. I observed Mike Dean using UNA in a large-scale application that we worked on together, and he was not apologetic, but he did acknowledge that doing so inherently contradicts OWL semantics (since it is non-monotonic). It would be much preferable if we could use UNA and CWA in combination with RDF and have Pat's blessing.
>
> From the IBM paper you reference:
>
>>>We apply the filtering criteria described in Section 3.2 to a canonical summary
>>>Abox AÂ