Investigate speed issues

[nsbgn]

Optimize SPARQL queries. FILTER NOT EXISTS is apparently not very fast.

[nsbgn]

It is mostly the ordering of tools that is prohibitively expensive. If there is no way to address this in SPARQL itself, it might be an option to pre-calculate a matrix of accessibility from each tool application.

[nsbgn]

I think it can be addressed via subqueries. Crucially, we should accept the first occurrence of a type on a particular branch (and not also investigate any subsequent occurrences)

[nsbgn]

For checking ordering, we now traverse the transformation graph along the :to predicates and check the type of each node. This is (predictably) incredibly computationally intensive, and I do think that we should eventually do this another way. However, it's useful to have it working for testing, so I want to try one more thing:

Since transformation graphs contain a type tree with all relevant types, we can work from the other direction: first select all nodes with the correct type, then check if they are accessible from the current node. This should be far less intensive.

We could also filter out those nodes with the correct type that are accessible from other nodes with the correct type.