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 <[email protected]> Sent: woensdag 20 november 2019 10:41 To: [email protected] 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) <[email protected]> > Sent: dinsdag 19 november 2019 16:49 > To: [email protected] > 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 <[email protected]> > Sent: dinsdag 19 november 2019 15:49 > To: [email protected] > 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. >
