Skip to content
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

Issue with backtracking after a succes #6

Open
arni360 opened this issue Jun 27, 2018 · 5 comments
Open

Issue with backtracking after a succes #6

arni360 opened this issue Jun 27, 2018 · 5 comments

Comments

@arni360
Copy link

arni360 commented Jun 27, 2018

Hi,

We have an issue with the backtracking when an homomorphism is found and another solution needs to keep a part of the current solution. The rule works in CoGUI.
hyp
In the image, so it found one solution and another is just to change the solide and the occurrence associated at the bottom.
In the graal code in the BacktrackIterator.java class the method private void backtrack(boolean failure) use (I think) an optimisation in case of success :

      int previousLevel = (failure) ?
      this.data.bj.previousLevel(this.currentVar().shared, this.vars) :
      this.currentVar().shared.previousLevel;

when removed - > int previousLevel = this.currentVar().shared.previousLevel; it works

here the rule in datalog
[R1_2_10_rolling_elements]inria:hasDesignation(X10,inria:rollingElement_i),inria:partOfBearing(X10,X11),rdf:type( inria:rollingElement_i , inria:rollingElement ):-inria:hasGeomRepresentation(X2,X1),inria:hasGeomRepresentation(X7,X6),inria:hasDesignation(X2,X4),inria:hasDesignation(X7,X5),inria:hasInterface(X1,X8),inria:hasInterfaceInHole(X6,X9),inria:hasInterface(X3,X8),inria:hasInterface(X3,X9),inria:hasGeomRepresentation(X10,X3),inria:partOfBearing(X2,X11),inria:partOfBearing(X7,X11),inria:partOfAlignment(X3,X12),rdf:type( X1 , inria:solid ),rdf:type( X12 , inria:circularTranslationalAlignment ),rdf:type( X6 , inria:solid ),rdf:type( X9 , inria:curvilinearContact ),rdf:type( X4 , inria:internalRing_Bearing ),rdf:type( X11 , inria:bearing ),rdf:type( X3 , inria:sphere ),rdf:type( X8 , inria:curvilinearContact ),rdf:type( X7 , inria:industrialProductComponent ),rdf:type( X5 , inria:externalRing_Bearing ),rdf:type( X2 , inria:industrialProductComponent ),rdf:type( X10 , inria:geomOccurrence ).
The datas :
rollCorrect000001.ttl.gz
bugrolling000001.ttl.gz

In this, the bugrolling file give what we've got at the end of the inferences so one application and the rollCorrect is what we have to have if the rule is fully applied.
The point property to check is inria:hasDesignation with the inria:rollingElement_i object : 1 in bugrolling, 7 in rollCorrect.

We use a connexion with Virtuoso and we rewrite the hierarchical property to avoid the saturation about that.

Thanks,

Harold Vilmart

@sipi
Copy link
Contributor

sipi commented Jun 28, 2018

Hi,
do you use the last version 1.3.1 ? There is such a bug in the 1.3.0.
Clément

@arni360
Copy link
Author

arni360 commented Jun 28, 2018

Hi,
I just upgrade it, but I've got the same issue. I've tested with SCCChase and ChaseWithGRD .
Do you want more informations about something?

Harold Vilmart

@sipi
Copy link
Contributor

sipi commented Jun 28, 2018

I think not, just more time…

@sipi
Copy link
Contributor

sipi commented Jul 3, 2018

Hi Harold,
Can you send me the initial data ?
Thanks

@arni360
Copy link
Author

arni360 commented Jul 3, 2018

Hi Clément,
bugrolling_start.zip
Technically the bugrolling000001.ttl.gz in my first message works too.

Harold Vilmart

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants