You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2017/11/22 21:27:24 UTC
ElementData.equalTo problem?
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.
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: ElementData.equalTo problem?
Posted by Claude Warren <cl...@xenei.com>.
thx -- I'll rework the query builder code then.
On Thu, Nov 23, 2017 at 6:22 PM, Andy Seaborne <an...@apache.org> wrote:
> >> 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 <cl...@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 <an...@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
>>>
>>>
>>
>>
>>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: ElementData.equalTo problem?
Posted by Andy Seaborne <an...@apache.org>.
>> 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 <cl...@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 <an...@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
>>
>
>
>
Re: ElementData.equalTo problem?
Posted by Claude Warren <cl...@xenei.com>.
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 <cl...@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 <an...@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
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: ElementData.equalTo problem?
Posted by Claude Warren <cl...@xenei.com>.
Andy,
Not "equals" but "equalTo". Does your point still hold for equalTo?
Claude
On Thu, Nov 23, 2017 at 10:18 AM, Andy Seaborne <an...@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
Re: ElementData.equalTo problem?
Posted by Andy Seaborne <an...@apache.org>.
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
>