Both Query and Op implement .equals(Object) and .hashCode() based on
structural equivalence. Query.equal is older (pre algebra!) - hence
having two.
The contract is that two queries being .equal will behave the same -
evaluate to the same results on any possible data and print the same.
Currently, it's structural equivalance + isomorphic equivalnce based on
mapping bNodes. Renaming bnodes consistently does not change the
answers because bNodes-as-variables can't be seen in the results.
hich is good, because the bNodes are probably named differently if they
are parser-generated anyway.
Q1 and Q3 are not equal by that definition. The column in the results
has been renamed from "v" to "y".
You could add that as a "IsomorphicByVaribleNames(query1, query2)" - but
as .equals() as it violates Javas rules for .equals().
The isomorphism is, luckily an easy case with no backtracking needed.
Just allocate an isomorphism mapping (it's carried around by
NodeIsomorphismMap for bNode labels - they really will be variables
called ??0 etc.) whenever an unseen thing is seen. All the
structuralisms that might need backtracking would make queries with
different print forms.
Andy
On 11/03/11 12:59, Damian Steer wrote:
On 11 Mar 2011, at 12:30, Damian Steer wrote:
The only difference between Q3 and Q1|Q2 is that we have a different
variable name (i.e. ?y instead of ?v). The queries are different, but
they are "equivalent": they are structurally the same, only variable
names are different.
I don't think it handles this (but I may be wrong).
Ah, Op#equalTo(Op other, NodeIsomorphismMap labelMap) would do that, once you
have the mapping.
Damian
