You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2019/12/01 09:57:57 UTC
Re: ElementPathBlock comparison
Barry,
Pull request #642 should fix this.
Either do the variable -> blank node replacement
and call IsoMatcher.isomorphic(graph,graph)
Or call the isomorphism algorithm code as follows:
Iso.Mappable mappable = (n1,n2) ->
( n1.isBlank() && n2.isBlank())
|| ( n1.isVariable() && n2.isVariable() );
List<Tuple<Node>> x1 = ...
List<Tuple<Node>> x2 = ...
boolean b =
IsoAlg.isIsomorphic(x1, x2, mappable, NodeUtils.sameValue);
The "mappable" is the rule for which terms are considered in the
isomorphism. The default and used by the main public functions is bnode
mapping.
IsoMatcher itself as a class is deprecated (its still there) and
everything is done with functions.
Andy
[1] https://github.com/apache/jena/pull/642
On 29/11/2019 12:16, Andy Seaborne wrote:
> Barry,
>
> It does look like something is wrong in iso-matching. Recorded as
> JENA-1789.
>
> Using graph1.isoIsomorphicWith(graph2)
>
> is a workaround.
>
> IsoMatcher "fails safe" for its use in the test suite and also its used
> there mainly on ResultSets not graphs.
>
> Andy
>
>
> On 28/11/2019 16:04, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks for the effort.
>>
>> If you clone this public github repository
>> (https://github.com/barrynl/jena-example) and set it us as a Maven
>> project and execute the main() in this Java class:
>>
>> https://github.com/barrynl/jena-example/blob/master/src/main/java/nl/tno/ict/ds/cb/jena/JenaIsomorphTest.java
>>
>>
>> it will show how converting variable nodes to blank nodes and using
>> the IsoMatcher yields true, while it should be false.
>>
>> Maybe you can find what I'm doing wrong.
>>
>> Thanks in advance!
>>
>> Barry
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: donderdag 28 november 2019 11:22
>> To: users@jena.apache.org
>> Subject: Re: ElementPathBlock comparison
>>
>>
>>
>> On 25/11/2019 13:52, Nouwt, B. (Barry) wrote:
>>> Hey Andy,
>>>
>>> I have another question about comparing ElementPathBlock's the way
>>> you suggest below using IsoMatcher.
>>>
>>> The following two graph patterns should (in my opinion and for my use
>>> case) not be the same, but the IsoMatcher says they match:
>>>
>>> graphpattern1: ?a <http://www.tno.nl/test1> ?b . ?b
>>> <http://www.tno.nl/test2> ?a .
>>>
>>> graphpattern2: ?a <http://www.tno.nl/test1> ?b . ?a
>>> <http://www.tno.nl/test2> ?b .
>>
>> They should be different.
>>
>> If it's _:a and _:b is it different? In which case the variable bit is
>> wrong.
>>
>>>
>>> Since RDF triples form a directed graph, this result surprises me,
>>> because in graphpattern1 the subject of /test1 has a single outgoing
>>> edge, while in graphpattern2 the subject of /test1 has two outgoing
>>> edges. How can this be judged the same?
>>>
>>> I've tested it in two ways:
>>> - converting all variables to blank nodes and using:
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new
>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>
>>> - or not converting them to blank nodes and using:
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new CustomBNodeIso(NodeUtils.sameValue));
>>>
>>> Where CustomBNodeIso adds the IF statement you suggest below.
>>>
>>> In both cases the above two graph patterns are judged the same while
>>> they shouldn't.
>>>
>>> Any idea what I'm doing wrong?
>>
>> Do you have a complete, mininal example I can copy-and-paste and run?
>>
>> If uou put it on a gist/pastebin I might find time to try it.
>>
>> Andy
>>
>>>
>>> Regards, Barry
>>>
>>> -----Original Message-----
>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>> Sent: donderdag 21 november 2019 13:03
>>> To: users@jena.apache.org
>>> Subject: RE: ElementPathBlock comparison
>>>
>>> Hey Andy, thanks. I'm currently testing the IsoMatcher - EqualityTest
>>> combination and the first tests look promising.
>>>
>>> I use the following code (where the gr1 and gr2 graphs have all
>>> variables of the graph pattern replaced by blanknodes):
>>>
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new
>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>
>>> but as I said, it requires some more testing. Not having to convert
>>> the variable into blanknodes would probably be more elegant, so maybe
>>> I'll try your suggestion below as well.
>>>
>>> Regards,
>>>
>>> Barry
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne <an...@apache.org>
>>> Sent: woensdag 20 november 2019 10:41
>>> To: users@jena.apache.org
>>> Subject: Re: ElementPathBlock comparison
>>>
>>>
>>>
>>> On 19/11/2019 15:52, Nouwt, B. (Barry) wrote:
>>>> Hi Andy, I have an additional question regarding your tip about
>>>> turning variables into blanknodes with names; would that also work
>>>> in case of predicates? Because variables can be located at the
>>>> 'predicate' location of a triple, but I'm unsure whether blanknodes
>>>> are allowed at that location.
>>>
>>> Yes.
>>>
>>> My recommendation is to write a EqualityTest that does variable
>>> isomorphism. It's a small chnage to the
>>>
>>> Copy BNodeIso and add the "if":
>>>
>>> if ( n1.isVariable() && n2.isVariable() )
>>> return mapping.makeIsomorphic(n1, n2) ;
>>>
>>> (not tested)
>>>
>>> Andy
>>>
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>> Sent: dinsdag 19 november 2019 16:49
>>>> To: users@jena.apache.org
>>>> Subject: RE: ElementPathBlock comparison
>>>>
>>>> Thanks for the quick replies.
>>>>
>>>> @Andy Exactly, I do care about the shape, but not about exact
>>>> variable names.
>>>>
>>>> I wanted to use Google Guava Graph library to construct the graphs
>>>> and use their equality mechanism, but I think the IsoMatcher is a
>>>> better fit, thanks for the pointer! This together with your tip
>>>> about transforming the same variable nodes into blank nodes with the
>>>> same name, it might just work in combination with BNodeIso. I'll
>>>> give that a try and report back the result.
>>>>
>>>> BTW In the comments of this IsoMatcher class, it says "For graphs,
>>>> the Graph isomorphism code in Jena is much better (better tested,
>>>> better performance)", is this relevant for me? And do you know which
>>>> isomorphism code in Jena is it referring to?
>>>>
>>>> @Martynas I could, indeed, encode the two BGPs into two RDF graphs
>>>> using sp:TriplePattern, but then I still a way to match them. For my
>>>> problem this RDF encoding is not necessary and encoding it using the
>>>> Google Guava Graph lib seems sufficient.
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Andy Seaborne <an...@apache.org>
>>>> Sent: dinsdag 19 november 2019 15:49
>>>> To: users@jena.apache.org
>>>> Subject: Re: ElementPathBlock comparison
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have two ARQ ElementPathBlocks (or Basic Graph Pattern, see
>>>>> SPARQL spec https://www.w3.org/TR/sparql11-query/#GraphPattern) and
>>>>> would like to know whether they are equal ignoring variable names
>>>>> and ordering of the triples. What is the best/easiest way to do
>>>>> that with the Apache Jena? I see there is an
>>>>> org.apache.jena.sparql.util.Iso class that provides methods for
>>>>> testing isomorphisms...but I'm unsure whether this is what I am
>>>>> looking for. I also tested two ElementPathBlocks and using their
>>>>> equalTo method (which uses the Iso class), but both variable names
>>>>> and order seems to matter judging them equal.
>>>>
>>>> I'm guessing you mean not caring about the variable names but
>>>> respecting the shape they create in the BGP.
>>>>
>>>> IsoMatcher is a simple algorithm for matching unordered lists
>>>> (Iso.isomorphic is ordered lists.)
>>>>
>>>> If you want to ignore variables names you'll need a "EqualityTest"
>>>> that captures that
>>>>
>>>>
>>>> BNodeIso does this for bnodes. Modifying that for a Var->Var map
>>>> loosk possible (or converting the input BGPs to have a bnode with
>>>> label derived from the Variable name).
>>>>
>>>> Andy
>>>> This message may contain information that is not intended for you.
>>>> If you are not the addressee or if this message was sent to you by
>>>> mistake, you are requested to inform the sender and delete the
>>>> message. TNO accepts no liability for the content of this e-mail,
>>>> for the manner in which you use it and for damage of any kind
>>>> resulting from the risks inherent to the electronic transmission of
>>>> messages.
>>>>
>>>
Re: ElementPathBlock comparison
Posted by Andy Seaborne <an...@apache.org>.
On 02/12/2019 16:44, Nouwt, B. (Barry) wrote:
> Hey Andy,
>
> It's easy. I just convert the graph pattern (ElementPathBlock) into a DefaultDirectedGraph (https://jgrapht.org/javadoc/org/jgrapht/graph/DefaultDirectedGraph.html) and add the correct edge/vertex comparators. With the two graphs and the two comparators, you instantiate the class VF2GraphIsomorphismInspector (https://jgrapht.org/javadoc/org/jgrapht/alg/isomorphism/VF2GraphIsomorphismInspector.html) and you can iterate over the isomorphisms/mappings.
>
> The only catch was that I could not use Jena's Node instances directly as edge objects in JGraphT (I could do this with the vertices), because their equals was too 'smart' for this purpose.
Straight into RDF* territory!
The URI of a property in a triple isn't identifying the triple; it is
the "class" of the edge, not the edge itself. The edge is the three
parts S-P-O.
Jena now has Node_Triple (experimental) to support work on extensions to
RDF (and Node_Graph)
This is what RDF* adds. It is either (RDF* PG mode - like property
graphs) adding triples into the RDF data model as a new kind of RDF Term
(in fact its abstractly a literal - it describes itself), or it is (RDF*
SA mode) a reference to a triple which may, or may not, be in the graph;
that's closer to reification.
Andy
> If you want I can add the JGraphT code in the github repo as well.
>
> Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: maandag 2 december 2019 14:32
> To: users@jena.apache.org
> Subject: Re: ElementPathBlock comparison
>
> Hi Barry,
>
> How easy is it to use JGraphT with Jena?
>
> I'd be very interested in hearing about your experiences.
>
> Andy
>
> On 02/12/2019 10:43, Nouwt, B. (Barry) wrote:
>> Hey Andy, thanks for the quick responses.
>>
>> For the time being I'm using JGraphT's isomorphism algorithm (VF2) and it works as expected.
>>
>> See: https://jgrapht.org/guide/UserOverview#graph-comparisons
>>
>> I might retry IsoMatcher/IsoAlg in the future.
>>
>> Regards, Barry
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: zondag 1 december 2019 10:58
>> To: users@jena.apache.org
>> Subject: Re: ElementPathBlock comparison
>>
>> Barry,
>>
>> Pull request #642 should fix this.
>>
>> Either do the variable -> blank node replacement and call
>> IsoMatcher.isomorphic(graph,graph)
>>
>>
>> Or call the isomorphism algorithm code as follows:
>>
>> Iso.Mappable mappable = (n1,n2) ->
>> ( n1.isBlank() && n2.isBlank())
>> || ( n1.isVariable() && n2.isVariable() );
>>
>> List<Tuple<Node>> x1 = ...
>> List<Tuple<Node>> x2 = ...
>>
>> boolean b =
>> IsoAlg.isIsomorphic(x1, x2, mappable, NodeUtils.sameValue);
>>
>> The "mappable" is the rule for which terms are considered in the isomorphism. The default and used by the main public functions is bnode mapping.
>>
>> IsoMatcher itself as a class is deprecated (its still there) and everything is done with functions.
>>
>> Andy
>>
>> [1] https://github.com/apache/jena/pull/642
>>
>> On 29/11/2019 12:16, Andy Seaborne wrote:
>>> Barry,
>>>
>>> It does look like something is wrong in iso-matching. Recorded as
>>> JENA-1789.
>>>
>>> Using graph1.isoIsomorphicWith(graph2)
>>>
>>> is a workaround.
>>>
>>> IsoMatcher "fails safe" for its use in the test suite and also its
>>> used there mainly on ResultSets not graphs.
>>>
>>> Andy
>>>
>>>
>>> On 28/11/2019 16:04, Nouwt, B. (Barry) wrote:
>>>> Hi Andy, thanks for the effort.
>>>>
>>>> If you clone this public github repository
>>>> (https://github.com/barrynl/jena-example) and set it us as a Maven
>>>> project and execute the main() in this Java class:
>>>>
>>>> https://github.com/barrynl/jena-example/blob/master/src/main/java/nl
>>>> / tno/ict/ds/cb/jena/JenaIsomorphTest.java
>>>>
>>>>
>>>> it will show how converting variable nodes to blank nodes and using
>>>> the IsoMatcher yields true, while it should be false.
>>>>
>>>> Maybe you can find what I'm doing wrong.
>>>>
>>>> Thanks in advance!
>>>>
>>>> Barry
>>>>
>>>> -----Original Message-----
>>>> From: Andy Seaborne <an...@apache.org>
>>>> Sent: donderdag 28 november 2019 11:22
>>>> To: users@jena.apache.org
>>>> Subject: Re: ElementPathBlock comparison
>>>>
>>>>
>>>>
>>>> On 25/11/2019 13:52, Nouwt, B. (Barry) wrote:
>>>>> Hey Andy,
>>>>>
>>>>> I have another question about comparing ElementPathBlock's the way
>>>>> you suggest below using IsoMatcher.
>>>>>
>>>>> The following two graph patterns should (in my opinion and for my
>>>>> use
>>>>> case) not be the same, but the IsoMatcher says they match:
>>>>>
>>>>> graphpattern1: ?a <http://www.tno.nl/test1> ?b . ?b
>>>>> <http://www.tno.nl/test2> ?a .
>>>>>
>>>>> graphpattern2: ?a <http://www.tno.nl/test1> ?b . ?a
>>>>> <http://www.tno.nl/test2> ?b .
>>>>
>>>> They should be different.
>>>>
>>>> If it's _:a and _:b is it different? In which case the variable bit
>>>> is wrong.
>>>>
>>>>>
>>>>> Since RDF triples form a directed graph, this result surprises me,
>>>>> because in graphpattern1 the subject of /test1 has a single
>>>>> outgoing edge, while in graphpattern2 the subject of /test1 has two
>>>>> outgoing edges. How can this be judged the same?
>>>>>
>>>>> I've tested it in two ways:
>>>>> - converting all variables to blank nodes and using:
>>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>>> tuplesTriples(gr2.find()), new
>>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>>
>>>>> - or not converting them to blank nodes and using:
>>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>>> tuplesTriples(gr2.find()), new
>>>>> CustomBNodeIso(NodeUtils.sameValue));
>>>>>
>>>>> Where CustomBNodeIso adds the IF statement you suggest below.
>>>>>
>>>>> In both cases the above two graph patterns are judged the same
>>>>> while they shouldn't.
>>>>>
>>>>> Any idea what I'm doing wrong?
>>>>
>>>> Do you have a complete, mininal example I can copy-and-paste and run?
>>>>
>>>> If uou put it on a gist/pastebin I might find time to try it.
>>>>
>>>> Andy
>>>>
>>>>>
>>>>> Regards, Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>>> Sent: donderdag 21 november 2019 13:03
>>>>> To: users@jena.apache.org
>>>>> Subject: RE: ElementPathBlock comparison
>>>>>
>>>>> Hey Andy, thanks. I'm currently testing the IsoMatcher -
>>>>> EqualityTest combination and the first tests look promising.
>>>>>
>>>>> I use the following code (where the gr1 and gr2 graphs have all
>>>>> variables of the graph pattern replaced by blanknodes):
>>>>>
>>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>>> tuplesTriples(gr2.find()), new
>>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>>
>>>>> but as I said, it requires some more testing. Not having to convert
>>>>> the variable into blanknodes would probably be more elegant, so
>>>>> maybe I'll try your suggestion below as well.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andy Seaborne <an...@apache.org>
>>>>> Sent: woensdag 20 november 2019 10:41
>>>>> To: users@jena.apache.org
>>>>> Subject: Re: ElementPathBlock comparison
>>>>>
>>>>>
>>>>>
>>>>> On 19/11/2019 15:52, Nouwt, B. (Barry) wrote:
>>>>>> Hi Andy, I have an additional question regarding your tip about
>>>>>> turning variables into blanknodes with names; would that also work
>>>>>> in case of predicates? Because variables can be located at the
>>>>>> 'predicate' location of a triple, but I'm unsure whether
>>>>>> blanknodes are allowed at that location.
>>>>>
>>>>> Yes.
>>>>>
>>>>> My recommendation is to write a EqualityTest that does variable
>>>>> isomorphism. It's a small chnage to the
>>>>>
>>>>> Copy BNodeIso and add the "if":
>>>>>
>>>>> if ( n1.isVariable() && n2.isVariable() )
>>>>> return mapping.makeIsomorphic(n1, n2) ;
>>>>>
>>>>> (not tested)
>>>>>
>>>>> Andy
>>>>>
>>>>>>
>>>>>> Regards, Barry
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>>>> Sent: dinsdag 19 november 2019 16:49
>>>>>> To: users@jena.apache.org
>>>>>> Subject: RE: ElementPathBlock comparison
>>>>>>
>>>>>> Thanks for the quick replies.
>>>>>>
>>>>>> @Andy Exactly, I do care about the shape, but not about exact
>>>>>> variable names.
>>>>>>
>>>>>> I wanted to use Google Guava Graph library to construct the graphs
>>>>>> and use their equality mechanism, but I think the IsoMatcher is a
>>>>>> better fit, thanks for the pointer! This together with your tip
>>>>>> about transforming the same variable nodes into blank nodes with
>>>>>> the same name, it might just work in combination with BNodeIso.
>>>>>> I'll give that a try and report back the result.
>>>>>>
>>>>>> BTW In the comments of this IsoMatcher class, it says "For graphs,
>>>>>> the Graph isomorphism code in Jena is much better (better tested,
>>>>>> better performance)", is this relevant for me? And do you know
>>>>>> which isomorphism code in Jena is it referring to?
>>>>>>
>>>>>> @Martynas I could, indeed, encode the two BGPs into two RDF graphs
>>>>>> using sp:TriplePattern, but then I still a way to match them. For
>>>>>> my problem this RDF encoding is not necessary and encoding it
>>>>>> using the Google Guava Graph lib seems sufficient.
>>>>>>
>>>>>> Regards, Barry
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Andy Seaborne <an...@apache.org>
>>>>>> Sent: dinsdag 19 november 2019 15:49
>>>>>> To: users@jena.apache.org
>>>>>> Subject: Re: ElementPathBlock comparison
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have two ARQ ElementPathBlocks (or Basic Graph Pattern, see
>>>>>>> SPARQL spec https://www.w3.org/TR/sparql11-query/#GraphPattern)
>>>>>>> and would like to know whether they are equal ignoring variable
>>>>>>> names and ordering of the triples. What is the best/easiest way
>>>>>>> to do that with the Apache Jena? I see there is an
>>>>>>> org.apache.jena.sparql.util.Iso class that provides methods for
>>>>>>> testing isomorphisms...but I'm unsure whether this is what I am
>>>>>>> looking for. I also tested two ElementPathBlocks and using their
>>>>>>> equalTo method (which uses the Iso class), but both variable
>>>>>>> names and order seems to matter judging them equal.
>>>>>>
>>>>>> I'm guessing you mean not caring about the variable names but
>>>>>> respecting the shape they create in the BGP.
>>>>>>
>>>>>> IsoMatcher is a simple algorithm for matching unordered lists
>>>>>> (Iso.isomorphic is ordered lists.)
>>>>>>
>>>>>> If you want to ignore variables names you'll need a "EqualityTest"
>>>>>> that captures that
>>>>>>
>>>>>>
>>>>>> BNodeIso does this for bnodes. Modifying that for a Var->Var map
>>>>>> loosk possible (or converting the input BGPs to have a bnode with
>>>>>> label derived from the Variable name).
>>>>>>
>>>>>> Andy
>>>>>> This message may contain information that is not intended for you.
>>>>>> If you are not the addressee or if this message was sent to you by
>>>>>> mistake, you are requested to inform the sender and delete the
>>>>>> message. TNO accepts no liability for the content of this e-mail,
>>>>>> for the manner in which you use it and for damage of any kind
>>>>>> resulting from the risks inherent to the electronic transmission
>>>>>> of messages.
>>>>>>
>>>>>
RE: ElementPathBlock comparison
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hey Andy,
It's easy. I just convert the graph pattern (ElementPathBlock) into a DefaultDirectedGraph (https://jgrapht.org/javadoc/org/jgrapht/graph/DefaultDirectedGraph.html) and add the correct edge/vertex comparators. With the two graphs and the two comparators, you instantiate the class VF2GraphIsomorphismInspector (https://jgrapht.org/javadoc/org/jgrapht/alg/isomorphism/VF2GraphIsomorphismInspector.html) and you can iterate over the isomorphisms/mappings.
The only catch was that I could not use Jena's Node instances directly as edge objects in JGraphT (I could do this with the vertices), because their equals was too 'smart' for this purpose.
If you want I can add the JGraphT code in the github repo as well.
Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: maandag 2 december 2019 14:32
To: users@jena.apache.org
Subject: Re: ElementPathBlock comparison
Hi Barry,
How easy is it to use JGraphT with Jena?
I'd be very interested in hearing about your experiences.
Andy
On 02/12/2019 10:43, Nouwt, B. (Barry) wrote:
> Hey Andy, thanks for the quick responses.
>
> For the time being I'm using JGraphT's isomorphism algorithm (VF2) and it works as expected.
>
> See: https://jgrapht.org/guide/UserOverview#graph-comparisons
>
> I might retry IsoMatcher/IsoAlg in the future.
>
> Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 1 december 2019 10:58
> To: users@jena.apache.org
> Subject: Re: ElementPathBlock comparison
>
> Barry,
>
> Pull request #642 should fix this.
>
> Either do the variable -> blank node replacement and call
> IsoMatcher.isomorphic(graph,graph)
>
>
> Or call the isomorphism algorithm code as follows:
>
> Iso.Mappable mappable = (n1,n2) ->
> ( n1.isBlank() && n2.isBlank())
> || ( n1.isVariable() && n2.isVariable() );
>
> List<Tuple<Node>> x1 = ...
> List<Tuple<Node>> x2 = ...
>
> boolean b =
> IsoAlg.isIsomorphic(x1, x2, mappable, NodeUtils.sameValue);
>
> The "mappable" is the rule for which terms are considered in the isomorphism. The default and used by the main public functions is bnode mapping.
>
> IsoMatcher itself as a class is deprecated (its still there) and everything is done with functions.
>
> Andy
>
> [1] https://github.com/apache/jena/pull/642
>
> On 29/11/2019 12:16, Andy Seaborne wrote:
>> Barry,
>>
>> It does look like something is wrong in iso-matching. Recorded as
>> JENA-1789.
>>
>> Using graph1.isoIsomorphicWith(graph2)
>>
>> is a workaround.
>>
>> IsoMatcher "fails safe" for its use in the test suite and also its
>> used there mainly on ResultSets not graphs.
>>
>> Andy
>>
>>
>> On 28/11/2019 16:04, Nouwt, B. (Barry) wrote:
>>> Hi Andy, thanks for the effort.
>>>
>>> If you clone this public github repository
>>> (https://github.com/barrynl/jena-example) and set it us as a Maven
>>> project and execute the main() in this Java class:
>>>
>>> https://github.com/barrynl/jena-example/blob/master/src/main/java/nl
>>> / tno/ict/ds/cb/jena/JenaIsomorphTest.java
>>>
>>>
>>> it will show how converting variable nodes to blank nodes and using
>>> the IsoMatcher yields true, while it should be false.
>>>
>>> Maybe you can find what I'm doing wrong.
>>>
>>> Thanks in advance!
>>>
>>> Barry
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne <an...@apache.org>
>>> Sent: donderdag 28 november 2019 11:22
>>> To: users@jena.apache.org
>>> Subject: Re: ElementPathBlock comparison
>>>
>>>
>>>
>>> On 25/11/2019 13:52, Nouwt, B. (Barry) wrote:
>>>> Hey Andy,
>>>>
>>>> I have another question about comparing ElementPathBlock's the way
>>>> you suggest below using IsoMatcher.
>>>>
>>>> The following two graph patterns should (in my opinion and for my
>>>> use
>>>> case) not be the same, but the IsoMatcher says they match:
>>>>
>>>> graphpattern1: ?a <http://www.tno.nl/test1> ?b . ?b
>>>> <http://www.tno.nl/test2> ?a .
>>>>
>>>> graphpattern2: ?a <http://www.tno.nl/test1> ?b . ?a
>>>> <http://www.tno.nl/test2> ?b .
>>>
>>> They should be different.
>>>
>>> If it's _:a and _:b is it different? In which case the variable bit
>>> is wrong.
>>>
>>>>
>>>> Since RDF triples form a directed graph, this result surprises me,
>>>> because in graphpattern1 the subject of /test1 has a single
>>>> outgoing edge, while in graphpattern2 the subject of /test1 has two
>>>> outgoing edges. How can this be judged the same?
>>>>
>>>> I've tested it in two ways:
>>>> - converting all variables to blank nodes and using:
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new
>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>
>>>> - or not converting them to blank nodes and using:
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new
>>>> CustomBNodeIso(NodeUtils.sameValue));
>>>>
>>>> Where CustomBNodeIso adds the IF statement you suggest below.
>>>>
>>>> In both cases the above two graph patterns are judged the same
>>>> while they shouldn't.
>>>>
>>>> Any idea what I'm doing wrong?
>>>
>>> Do you have a complete, mininal example I can copy-and-paste and run?
>>>
>>> If uou put it on a gist/pastebin I might find time to try it.
>>>
>>> Andy
>>>
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>> Sent: donderdag 21 november 2019 13:03
>>>> To: users@jena.apache.org
>>>> Subject: RE: ElementPathBlock comparison
>>>>
>>>> Hey Andy, thanks. I'm currently testing the IsoMatcher -
>>>> EqualityTest combination and the first tests look promising.
>>>>
>>>> I use the following code (where the gr1 and gr2 graphs have all
>>>> variables of the graph pattern replaced by blanknodes):
>>>>
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new
>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>
>>>> but as I said, it requires some more testing. Not having to convert
>>>> the variable into blanknodes would probably be more elegant, so
>>>> maybe I'll try your suggestion below as well.
>>>>
>>>> Regards,
>>>>
>>>> Barry
>>>>
>>>> -----Original Message-----
>>>> From: Andy Seaborne <an...@apache.org>
>>>> Sent: woensdag 20 november 2019 10:41
>>>> To: users@jena.apache.org
>>>> Subject: Re: ElementPathBlock comparison
>>>>
>>>>
>>>>
>>>> On 19/11/2019 15:52, Nouwt, B. (Barry) wrote:
>>>>> Hi Andy, I have an additional question regarding your tip about
>>>>> turning variables into blanknodes with names; would that also work
>>>>> in case of predicates? Because variables can be located at the
>>>>> 'predicate' location of a triple, but I'm unsure whether
>>>>> blanknodes are allowed at that location.
>>>>
>>>> Yes.
>>>>
>>>> My recommendation is to write a EqualityTest that does variable
>>>> isomorphism. It's a small chnage to the
>>>>
>>>> Copy BNodeIso and add the "if":
>>>>
>>>> if ( n1.isVariable() && n2.isVariable() )
>>>> return mapping.makeIsomorphic(n1, n2) ;
>>>>
>>>> (not tested)
>>>>
>>>> Andy
>>>>
>>>>>
>>>>> Regards, Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>>> Sent: dinsdag 19 november 2019 16:49
>>>>> To: users@jena.apache.org
>>>>> Subject: RE: ElementPathBlock comparison
>>>>>
>>>>> Thanks for the quick replies.
>>>>>
>>>>> @Andy Exactly, I do care about the shape, but not about exact
>>>>> variable names.
>>>>>
>>>>> I wanted to use Google Guava Graph library to construct the graphs
>>>>> and use their equality mechanism, but I think the IsoMatcher is a
>>>>> better fit, thanks for the pointer! This together with your tip
>>>>> about transforming the same variable nodes into blank nodes with
>>>>> the same name, it might just work in combination with BNodeIso.
>>>>> I'll give that a try and report back the result.
>>>>>
>>>>> BTW In the comments of this IsoMatcher class, it says "For graphs,
>>>>> the Graph isomorphism code in Jena is much better (better tested,
>>>>> better performance)", is this relevant for me? And do you know
>>>>> which isomorphism code in Jena is it referring to?
>>>>>
>>>>> @Martynas I could, indeed, encode the two BGPs into two RDF graphs
>>>>> using sp:TriplePattern, but then I still a way to match them. For
>>>>> my problem this RDF encoding is not necessary and encoding it
>>>>> using the Google Guava Graph lib seems sufficient.
>>>>>
>>>>> Regards, Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andy Seaborne <an...@apache.org>
>>>>> Sent: dinsdag 19 november 2019 15:49
>>>>> To: users@jena.apache.org
>>>>> Subject: Re: ElementPathBlock comparison
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have two ARQ ElementPathBlocks (or Basic Graph Pattern, see
>>>>>> SPARQL spec https://www.w3.org/TR/sparql11-query/#GraphPattern)
>>>>>> and would like to know whether they are equal ignoring variable
>>>>>> names and ordering of the triples. What is the best/easiest way
>>>>>> to do that with the Apache Jena? I see there is an
>>>>>> org.apache.jena.sparql.util.Iso class that provides methods for
>>>>>> testing isomorphisms...but I'm unsure whether this is what I am
>>>>>> looking for. I also tested two ElementPathBlocks and using their
>>>>>> equalTo method (which uses the Iso class), but both variable
>>>>>> names and order seems to matter judging them equal.
>>>>>
>>>>> I'm guessing you mean not caring about the variable names but
>>>>> respecting the shape they create in the BGP.
>>>>>
>>>>> IsoMatcher is a simple algorithm for matching unordered lists
>>>>> (Iso.isomorphic is ordered lists.)
>>>>>
>>>>> If you want to ignore variables names you'll need a "EqualityTest"
>>>>> that captures that
>>>>>
>>>>>
>>>>> BNodeIso does this for bnodes. Modifying that for a Var->Var map
>>>>> loosk possible (or converting the input BGPs to have a bnode with
>>>>> label derived from the Variable name).
>>>>>
>>>>> Andy
>>>>> This message may contain information that is not intended for you.
>>>>> If you are not the addressee or if this message was sent to you by
>>>>> mistake, you are requested to inform the sender and delete the
>>>>> message. TNO accepts no liability for the content of this e-mail,
>>>>> for the manner in which you use it and for damage of any kind
>>>>> resulting from the risks inherent to the electronic transmission
>>>>> of messages.
>>>>>
>>>>
Re: ElementPathBlock comparison
Posted by Andy Seaborne <an...@apache.org>.
Hi Barry,
How easy is it to use JGraphT with Jena?
I'd be very interested in hearing about your experiences.
Andy
On 02/12/2019 10:43, Nouwt, B. (Barry) wrote:
> Hey Andy, thanks for the quick responses.
>
> For the time being I'm using JGraphT's isomorphism algorithm (VF2) and it works as expected.
>
> See: https://jgrapht.org/guide/UserOverview#graph-comparisons
>
> I might retry IsoMatcher/IsoAlg in the future.
>
> Regards, Barry
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 1 december 2019 10:58
> To: users@jena.apache.org
> Subject: Re: ElementPathBlock comparison
>
> Barry,
>
> Pull request #642 should fix this.
>
> Either do the variable -> blank node replacement and call IsoMatcher.isomorphic(graph,graph)
>
>
> Or call the isomorphism algorithm code as follows:
>
> Iso.Mappable mappable = (n1,n2) ->
> ( n1.isBlank() && n2.isBlank())
> || ( n1.isVariable() && n2.isVariable() );
>
> List<Tuple<Node>> x1 = ...
> List<Tuple<Node>> x2 = ...
>
> boolean b =
> IsoAlg.isIsomorphic(x1, x2, mappable, NodeUtils.sameValue);
>
> The "mappable" is the rule for which terms are considered in the isomorphism. The default and used by the main public functions is bnode mapping.
>
> IsoMatcher itself as a class is deprecated (its still there) and everything is done with functions.
>
> Andy
>
> [1] https://github.com/apache/jena/pull/642
>
> On 29/11/2019 12:16, Andy Seaborne wrote:
>> Barry,
>>
>> It does look like something is wrong in iso-matching. Recorded as
>> JENA-1789.
>>
>> Using graph1.isoIsomorphicWith(graph2)
>>
>> is a workaround.
>>
>> IsoMatcher "fails safe" for its use in the test suite and also its
>> used there mainly on ResultSets not graphs.
>>
>> Andy
>>
>>
>> On 28/11/2019 16:04, Nouwt, B. (Barry) wrote:
>>> Hi Andy, thanks for the effort.
>>>
>>> If you clone this public github repository
>>> (https://github.com/barrynl/jena-example) and set it us as a Maven
>>> project and execute the main() in this Java class:
>>>
>>> https://github.com/barrynl/jena-example/blob/master/src/main/java/nl/
>>> tno/ict/ds/cb/jena/JenaIsomorphTest.java
>>>
>>>
>>> it will show how converting variable nodes to blank nodes and using
>>> the IsoMatcher yields true, while it should be false.
>>>
>>> Maybe you can find what I'm doing wrong.
>>>
>>> Thanks in advance!
>>>
>>> Barry
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne <an...@apache.org>
>>> Sent: donderdag 28 november 2019 11:22
>>> To: users@jena.apache.org
>>> Subject: Re: ElementPathBlock comparison
>>>
>>>
>>>
>>> On 25/11/2019 13:52, Nouwt, B. (Barry) wrote:
>>>> Hey Andy,
>>>>
>>>> I have another question about comparing ElementPathBlock's the way
>>>> you suggest below using IsoMatcher.
>>>>
>>>> The following two graph patterns should (in my opinion and for my
>>>> use
>>>> case) not be the same, but the IsoMatcher says they match:
>>>>
>>>> graphpattern1: ?a <http://www.tno.nl/test1> ?b . ?b
>>>> <http://www.tno.nl/test2> ?a .
>>>>
>>>> graphpattern2: ?a <http://www.tno.nl/test1> ?b . ?a
>>>> <http://www.tno.nl/test2> ?b .
>>>
>>> They should be different.
>>>
>>> If it's _:a and _:b is it different? In which case the variable bit
>>> is wrong.
>>>
>>>>
>>>> Since RDF triples form a directed graph, this result surprises me,
>>>> because in graphpattern1 the subject of /test1 has a single outgoing
>>>> edge, while in graphpattern2 the subject of /test1 has two outgoing
>>>> edges. How can this be judged the same?
>>>>
>>>> I've tested it in two ways:
>>>> - converting all variables to blank nodes and using:
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new
>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>
>>>> - or not converting them to blank nodes and using:
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new CustomBNodeIso(NodeUtils.sameValue));
>>>>
>>>> Where CustomBNodeIso adds the IF statement you suggest below.
>>>>
>>>> In both cases the above two graph patterns are judged the same while
>>>> they shouldn't.
>>>>
>>>> Any idea what I'm doing wrong?
>>>
>>> Do you have a complete, mininal example I can copy-and-paste and run?
>>>
>>> If uou put it on a gist/pastebin I might find time to try it.
>>>
>>> Andy
>>>
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>> Sent: donderdag 21 november 2019 13:03
>>>> To: users@jena.apache.org
>>>> Subject: RE: ElementPathBlock comparison
>>>>
>>>> Hey Andy, thanks. I'm currently testing the IsoMatcher -
>>>> EqualityTest combination and the first tests look promising.
>>>>
>>>> I use the following code (where the gr1 and gr2 graphs have all
>>>> variables of the graph pattern replaced by blanknodes):
>>>>
>>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>>> tuplesTriples(gr2.find()), new
>>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>>
>>>> but as I said, it requires some more testing. Not having to convert
>>>> the variable into blanknodes would probably be more elegant, so
>>>> maybe I'll try your suggestion below as well.
>>>>
>>>> Regards,
>>>>
>>>> Barry
>>>>
>>>> -----Original Message-----
>>>> From: Andy Seaborne <an...@apache.org>
>>>> Sent: woensdag 20 november 2019 10:41
>>>> To: users@jena.apache.org
>>>> Subject: Re: ElementPathBlock comparison
>>>>
>>>>
>>>>
>>>> On 19/11/2019 15:52, Nouwt, B. (Barry) wrote:
>>>>> Hi Andy, I have an additional question regarding your tip about
>>>>> turning variables into blanknodes with names; would that also work
>>>>> in case of predicates? Because variables can be located at the
>>>>> 'predicate' location of a triple, but I'm unsure whether blanknodes
>>>>> are allowed at that location.
>>>>
>>>> Yes.
>>>>
>>>> My recommendation is to write a EqualityTest that does variable
>>>> isomorphism. It's a small chnage to the
>>>>
>>>> Copy BNodeIso and add the "if":
>>>>
>>>> if ( n1.isVariable() && n2.isVariable() )
>>>> return mapping.makeIsomorphic(n1, n2) ;
>>>>
>>>> (not tested)
>>>>
>>>> Andy
>>>>
>>>>>
>>>>> Regards, Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>>> Sent: dinsdag 19 november 2019 16:49
>>>>> To: users@jena.apache.org
>>>>> Subject: RE: ElementPathBlock comparison
>>>>>
>>>>> Thanks for the quick replies.
>>>>>
>>>>> @Andy Exactly, I do care about the shape, but not about exact
>>>>> variable names.
>>>>>
>>>>> I wanted to use Google Guava Graph library to construct the graphs
>>>>> and use their equality mechanism, but I think the IsoMatcher is a
>>>>> better fit, thanks for the pointer! This together with your tip
>>>>> about transforming the same variable nodes into blank nodes with
>>>>> the same name, it might just work in combination with BNodeIso.
>>>>> I'll give that a try and report back the result.
>>>>>
>>>>> BTW In the comments of this IsoMatcher class, it says "For graphs,
>>>>> the Graph isomorphism code in Jena is much better (better tested,
>>>>> better performance)", is this relevant for me? And do you know
>>>>> which isomorphism code in Jena is it referring to?
>>>>>
>>>>> @Martynas I could, indeed, encode the two BGPs into two RDF graphs
>>>>> using sp:TriplePattern, but then I still a way to match them. For
>>>>> my problem this RDF encoding is not necessary and encoding it using
>>>>> the Google Guava Graph lib seems sufficient.
>>>>>
>>>>> Regards, Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andy Seaborne <an...@apache.org>
>>>>> Sent: dinsdag 19 november 2019 15:49
>>>>> To: users@jena.apache.org
>>>>> Subject: Re: ElementPathBlock comparison
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have two ARQ ElementPathBlocks (or Basic Graph Pattern, see
>>>>>> SPARQL spec https://www.w3.org/TR/sparql11-query/#GraphPattern)
>>>>>> and would like to know whether they are equal ignoring variable
>>>>>> names and ordering of the triples. What is the best/easiest way to
>>>>>> do that with the Apache Jena? I see there is an
>>>>>> org.apache.jena.sparql.util.Iso class that provides methods for
>>>>>> testing isomorphisms...but I'm unsure whether this is what I am
>>>>>> looking for. I also tested two ElementPathBlocks and using their
>>>>>> equalTo method (which uses the Iso class), but both variable names
>>>>>> and order seems to matter judging them equal.
>>>>>
>>>>> I'm guessing you mean not caring about the variable names but
>>>>> respecting the shape they create in the BGP.
>>>>>
>>>>> IsoMatcher is a simple algorithm for matching unordered lists
>>>>> (Iso.isomorphic is ordered lists.)
>>>>>
>>>>> If you want to ignore variables names you'll need a "EqualityTest"
>>>>> that captures that
>>>>>
>>>>>
>>>>> BNodeIso does this for bnodes. Modifying that for a Var->Var map
>>>>> loosk possible (or converting the input BGPs to have a bnode with
>>>>> label derived from the Variable name).
>>>>>
>>>>> Andy
>>>>> This message may contain information that is not intended for you.
>>>>> If you are not the addressee or if this message was sent to you by
>>>>> mistake, you are requested to inform the sender and delete the
>>>>> message. TNO accepts no liability for the content of this e-mail,
>>>>> for the manner in which you use it and for damage of any kind
>>>>> resulting from the risks inherent to the electronic transmission of
>>>>> messages.
>>>>>
>>>>
RE: ElementPathBlock comparison
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hey Andy, thanks for the quick responses.
For the time being I'm using JGraphT's isomorphism algorithm (VF2) and it works as expected.
See: https://jgrapht.org/guide/UserOverview#graph-comparisons
I might retry IsoMatcher/IsoAlg in the future.
Regards, Barry
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: zondag 1 december 2019 10:58
To: users@jena.apache.org
Subject: Re: ElementPathBlock comparison
Barry,
Pull request #642 should fix this.
Either do the variable -> blank node replacement and call IsoMatcher.isomorphic(graph,graph)
Or call the isomorphism algorithm code as follows:
Iso.Mappable mappable = (n1,n2) ->
( n1.isBlank() && n2.isBlank())
|| ( n1.isVariable() && n2.isVariable() );
List<Tuple<Node>> x1 = ...
List<Tuple<Node>> x2 = ...
boolean b =
IsoAlg.isIsomorphic(x1, x2, mappable, NodeUtils.sameValue);
The "mappable" is the rule for which terms are considered in the isomorphism. The default and used by the main public functions is bnode mapping.
IsoMatcher itself as a class is deprecated (its still there) and everything is done with functions.
Andy
[1] https://github.com/apache/jena/pull/642
On 29/11/2019 12:16, Andy Seaborne wrote:
> Barry,
>
> It does look like something is wrong in iso-matching. Recorded as
> JENA-1789.
>
> Using graph1.isoIsomorphicWith(graph2)
>
> is a workaround.
>
> IsoMatcher "fails safe" for its use in the test suite and also its
> used there mainly on ResultSets not graphs.
>
> Andy
>
>
> On 28/11/2019 16:04, Nouwt, B. (Barry) wrote:
>> Hi Andy, thanks for the effort.
>>
>> If you clone this public github repository
>> (https://github.com/barrynl/jena-example) and set it us as a Maven
>> project and execute the main() in this Java class:
>>
>> https://github.com/barrynl/jena-example/blob/master/src/main/java/nl/
>> tno/ict/ds/cb/jena/JenaIsomorphTest.java
>>
>>
>> it will show how converting variable nodes to blank nodes and using
>> the IsoMatcher yields true, while it should be false.
>>
>> Maybe you can find what I'm doing wrong.
>>
>> Thanks in advance!
>>
>> Barry
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: donderdag 28 november 2019 11:22
>> To: users@jena.apache.org
>> Subject: Re: ElementPathBlock comparison
>>
>>
>>
>> On 25/11/2019 13:52, Nouwt, B. (Barry) wrote:
>>> Hey Andy,
>>>
>>> I have another question about comparing ElementPathBlock's the way
>>> you suggest below using IsoMatcher.
>>>
>>> The following two graph patterns should (in my opinion and for my
>>> use
>>> case) not be the same, but the IsoMatcher says they match:
>>>
>>> graphpattern1: ?a <http://www.tno.nl/test1> ?b . ?b
>>> <http://www.tno.nl/test2> ?a .
>>>
>>> graphpattern2: ?a <http://www.tno.nl/test1> ?b . ?a
>>> <http://www.tno.nl/test2> ?b .
>>
>> They should be different.
>>
>> If it's _:a and _:b is it different? In which case the variable bit
>> is wrong.
>>
>>>
>>> Since RDF triples form a directed graph, this result surprises me,
>>> because in graphpattern1 the subject of /test1 has a single outgoing
>>> edge, while in graphpattern2 the subject of /test1 has two outgoing
>>> edges. How can this be judged the same?
>>>
>>> I've tested it in two ways:
>>> - converting all variables to blank nodes and using:
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new
>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>
>>> - or not converting them to blank nodes and using:
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new CustomBNodeIso(NodeUtils.sameValue));
>>>
>>> Where CustomBNodeIso adds the IF statement you suggest below.
>>>
>>> In both cases the above two graph patterns are judged the same while
>>> they shouldn't.
>>>
>>> Any idea what I'm doing wrong?
>>
>> Do you have a complete, mininal example I can copy-and-paste and run?
>>
>> If uou put it on a gist/pastebin I might find time to try it.
>>
>> Andy
>>
>>>
>>> Regards, Barry
>>>
>>> -----Original Message-----
>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>> Sent: donderdag 21 november 2019 13:03
>>> To: users@jena.apache.org
>>> Subject: RE: ElementPathBlock comparison
>>>
>>> Hey Andy, thanks. I'm currently testing the IsoMatcher -
>>> EqualityTest combination and the first tests look promising.
>>>
>>> I use the following code (where the gr1 and gr2 graphs have all
>>> variables of the graph pattern replaced by blanknodes):
>>>
>>> IsoMatcher match = new IsoMatcher(tuplesTriples(gr1.find()),
>>> tuplesTriples(gr2.find()), new
>>> ResultSetCompare.BNodeIso(NodeUtils.sameValue));
>>>
>>> but as I said, it requires some more testing. Not having to convert
>>> the variable into blanknodes would probably be more elegant, so
>>> maybe I'll try your suggestion below as well.
>>>
>>> Regards,
>>>
>>> Barry
>>>
>>> -----Original Message-----
>>> From: Andy Seaborne <an...@apache.org>
>>> Sent: woensdag 20 november 2019 10:41
>>> To: users@jena.apache.org
>>> Subject: Re: ElementPathBlock comparison
>>>
>>>
>>>
>>> On 19/11/2019 15:52, Nouwt, B. (Barry) wrote:
>>>> Hi Andy, I have an additional question regarding your tip about
>>>> turning variables into blanknodes with names; would that also work
>>>> in case of predicates? Because variables can be located at the
>>>> 'predicate' location of a triple, but I'm unsure whether blanknodes
>>>> are allowed at that location.
>>>
>>> Yes.
>>>
>>> My recommendation is to write a EqualityTest that does variable
>>> isomorphism. It's a small chnage to the
>>>
>>> Copy BNodeIso and add the "if":
>>>
>>> if ( n1.isVariable() && n2.isVariable() )
>>> return mapping.makeIsomorphic(n1, n2) ;
>>>
>>> (not tested)
>>>
>>> Andy
>>>
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Nouwt, B. (Barry) <ba...@tno.nl.INVALID>
>>>> Sent: dinsdag 19 november 2019 16:49
>>>> To: users@jena.apache.org
>>>> Subject: RE: ElementPathBlock comparison
>>>>
>>>> Thanks for the quick replies.
>>>>
>>>> @Andy Exactly, I do care about the shape, but not about exact
>>>> variable names.
>>>>
>>>> I wanted to use Google Guava Graph library to construct the graphs
>>>> and use their equality mechanism, but I think the IsoMatcher is a
>>>> better fit, thanks for the pointer! This together with your tip
>>>> about transforming the same variable nodes into blank nodes with
>>>> the same name, it might just work in combination with BNodeIso.
>>>> I'll give that a try and report back the result.
>>>>
>>>> BTW In the comments of this IsoMatcher class, it says "For graphs,
>>>> the Graph isomorphism code in Jena is much better (better tested,
>>>> better performance)", is this relevant for me? And do you know
>>>> which isomorphism code in Jena is it referring to?
>>>>
>>>> @Martynas I could, indeed, encode the two BGPs into two RDF graphs
>>>> using sp:TriplePattern, but then I still a way to match them. For
>>>> my problem this RDF encoding is not necessary and encoding it using
>>>> the Google Guava Graph lib seems sufficient.
>>>>
>>>> Regards, Barry
>>>>
>>>> -----Original Message-----
>>>> From: Andy Seaborne <an...@apache.org>
>>>> Sent: dinsdag 19 november 2019 15:49
>>>> To: users@jena.apache.org
>>>> Subject: Re: ElementPathBlock comparison
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have two ARQ ElementPathBlocks (or Basic Graph Pattern, see
>>>>> SPARQL spec https://www.w3.org/TR/sparql11-query/#GraphPattern)
>>>>> and would like to know whether they are equal ignoring variable
>>>>> names and ordering of the triples. What is the best/easiest way to
>>>>> do that with the Apache Jena? I see there is an
>>>>> org.apache.jena.sparql.util.Iso class that provides methods for
>>>>> testing isomorphisms...but I'm unsure whether this is what I am
>>>>> looking for. I also tested two ElementPathBlocks and using their
>>>>> equalTo method (which uses the Iso class), but both variable names
>>>>> and order seems to matter judging them equal.
>>>>
>>>> I'm guessing you mean not caring about the variable names but
>>>> respecting the shape they create in the BGP.
>>>>
>>>> IsoMatcher is a simple algorithm for matching unordered lists
>>>> (Iso.isomorphic is ordered lists.)
>>>>
>>>> If you want to ignore variables names you'll need a "EqualityTest"
>>>> that captures that
>>>>
>>>>
>>>> BNodeIso does this for bnodes. Modifying that for a Var->Var map
>>>> loosk possible (or converting the input BGPs to have a bnode with
>>>> label derived from the Variable name).
>>>>
>>>> Andy
>>>> This message may contain information that is not intended for you.
>>>> If you are not the addressee or if this message was sent to you by
>>>> mistake, you are requested to inform the sender and delete the
>>>> message. TNO accepts no liability for the content of this e-mail,
>>>> for the manner in which you use it and for damage of any kind
>>>> resulting from the risks inherent to the electronic transmission of
>>>> messages.
>>>>
>>>