>> Not "equals" but "equalTo". Does your point still hold for equalTo?
yes - "equalTo" is simply "equals" with blank node isomorphism considered.
A reparsed query string has new blank nodes.
So for two query strings to be equal, tested by parsing (same AST), it
needs to have blank node isomorphism.
Andy
On 23/11/17 17:55, Claude Warren wrote:
equalTo is used in the isIsomorphicWith(Model g) method. So I guess the
question becomes are the two element data objects equivalent for purposes
of isomorphic comparison?
Claude
On Thu, Nov 23, 2017 at 5:27 PM, Claude Warren <cla...@xenei.com> wrote:
Andy,
Not "equals" but "equalTo". Does your point still hold for equalTo?
Claude
On Thu, Nov 23, 2017 at 10:18 AM, Andy Seaborne <a...@apache.org> wrote:
On 22/11/17 21:27, Claude Warren wrote:
I think equalTo for ElementData is not correct. Given 2 ElementData
instances
ElementData 1:
{noformat}
VALUES ( ?x ?v ) {
( "three" <one> )
( "four" <two> )
}
{noformat}
ElementData 2:
{noformat}
VALUES ( ?v ?x ) {
( <one> "three" )
( <two> "four" )
}
{noformat}
shouldn't the equalTo() method return true.
Currently it is sensitive to the ordering of the vars.
I can put a fix in but I want to be sure that there is an error first.
It's not an error.
Element* are syntax. and ".equals" is a syntax test, not a semantic test.
The variables are in a different order and in synatx that is significant.
This is true throughout the abstract syntax provided by Element*. There
are lots of ways to write "the same" query. .equals means "same abstract
syntax".
Try "qparse" - it always checks the query round-trips as well as printing
it.
Andy
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
