Query diagnostics

[nsbgn]

For real-life examples, it is often hard to see why a particular query does not find the corresponding workflow we would expect. An explanation module would help: it would trace every step and tell you why a query does not find a result for a particular graph, that is, show you the first point at which the two diverge.

[nsbgn]

We will need diagnostics also: how many types occur in each workflow? How many of those are in the right order? How many operators occur in each? Etcetera.

[nsbgn]

https://blog.soton.ac.uk/webteam/2011/03/02/rdf-sparql-debugging/ Automate this?

[nsbgn]

If you query for [A, f], e.g. a type A that eventually results from operation
f, then if you find no f on the branch before A, clearly it makes no sense to
search for another A on that branch that occurs before the other A --- there
will still not be an A. This should be optimized, but a test should make sure
that other branches are still inspected:

A <-- ... <- g
    `- ... <- f

[nsbgn]

See also:

• https://graphdb.ontotext.com/free/explain-plan.html
• https://server.marklogic.com/blog/performance-checklist
• https://composing-the-semantic-web.blogspot.com/2009/11/sparql-debugger-and-profiler.html

[nsbgn]

Cf commit e9ed04c.

[nsbgn]

Every node should get a unique label so it's easier to see what happens.