-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GraphMatcher edge case? #235
Milestone
Comments
langsamu
added a commit
to langsamu/dotnetrdf
that referenced
this issue
Apr 3, 2019
Merged
kal
pushed a commit
that referenced
this issue
Apr 22, 2019
Fixes a bug in the brute-force graph matching algorithm that doesn't correctly handle the case of a base mapping being specified that is not contained in the list of possible mappings. Fixes #235
kal
added a commit
that referenced
this issue
Apr 22, 2019
Quite an Easter Monday @kal. Thx! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider two graphs loaded from the following Turtle strings:
They differ only in the order of URI object nodes of the blank objects of the first blank node (XXYY vs XYXY).
They both consist of the following statements:
_:b
<urn:p>
_:x1
_:b
<urn:p>
_:x2
_:b
<urn:p>
_:y1
_:b
<urn:p>
_:y2
_:x1
<urn:p>
<urn:X>
_:x2
<urn:p>
<urn:X>
_:y1
<urn:p>
<urn:Y>
_:y2
<urn:p>
<urn:Y>
Or visually:

Yet they're not equal:
I've traced things as far as learning that GraphMatcher resorts to brute force mapping for this topology, which probably explains the abhoring growth rate:
XYXY
XXYXY
XXXYXY
XXXXYXY
But it doesn't explain why they're not considered isomorphic.
The text was updated successfully, but these errors were encountered: