There is a bug in the following method:

Substitution fr.lirmm.graphik.graal.homomorphism.Atom2SubstitutionConverter.convert(Atom object) throws ConversionException

where

s.put((Variable) var, object.getTerm(variables.get(var)));

is performed without checking that variables.get(var) returns non-null Integer, and getTerm(int index) takes a primitive int value. In the event that variables does not contain var it will return null, which produces the NullPointerException. A solution (that works in my clone) is the following:

s.put((Variable) var, object.getTerm(variables.get(var)==null?0:variables.get(var)));

However, it is unclear to me if this would preserve the intended behaviour of the method. It works with my dataset so far.

I know that 1.2.1-SNAPSHOT is still a snapshot :p, and that this kind of issues is to be expected, but I will just put this here so that we don't forget about it later.

Latest version of Graal 1.2.1-SNAPSHOT no longer compiles as it references a non released external maven project dlgp2-parser. This project can be found here, but it needs to be compiled using javacc before being able to use it, and it needs to be unsigned to be able to mvn intall it.

I think that:

1. The dlgp2-parser should include compiled files for ease of use.
2. Either use a release version of dlgp2-parser or include it inside the graal project as a module.

Thanks :)

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.

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

I move data between different tools and land up having to mangle the names because of how restricted the characters for labels and terms are. I'd like to suggest that labels and terms be able to use most characters, with either a quote or escape mechanism, i.e, if PN_CHARS stays default
either
['I can say anything here!'] 'part-of'(X,'3d-space') :- 'instance-of'(X,'2d-space').
or
[I can say anything here\!] part\-of(X,\3d\-space) :- instance\-of(X,\2d\-space).

or better, open up the range of usable characters (and still allow the escape/quote for characters that would otherwise be reserved)

I don't know if terms and labels can be less restrictive if the API is used to build structures rather than the Parser. If that's the case I suppose I could go that route, but enhancing the parser is preferable.

Hi,

I was wondering if Graal was allowing the negation of facts/rules:

@facts
u(1, 1, "garantie").
u(1, 2, "non").
u(1, 3, "souscrite").

u(2, 1, "garantie").
u(2, 2, "souscrite").

@rules
garantie_non_souscrite(X) :- u(X, A, "garantie"), u(X, B, "non"), u(X, C, "souscrite").
garantie_souscrite(X) :- u(X, A, "garantie"), u(X, B, "souscrite"), not garantie_non_souscrite(X).

@queries
?(X) :- garantie_souscrite(X). % Expected: X=2

Hi,

I'm trying to use DefaultKnowledgeBase to do some forward chaining. I use a KbBuilder, adding facts and rules, and then build to get a DefaultKnowledgeBase. Following one of the tests I thought I could call saturate, and then getFacts.

However, if I do this I get I get a runtime exception "Edge factory failed'.

If instead I set the approach to be SATURATION_ONLY, then I get a NullPointerException.

However, if I first do a query (still approach SATURATION_ONLY) then after that I can call saturate without error.

Last fact. A call to fesSaturate (via reflection) will succeed even before a query is made, although again only with approach SATURATION_ONLY

FWIW, I checked my rules with the online tool and it reports decidable FES, which was my expectation.

I'm using maven artifacts "fr.lirmm.graphik:graal-kb:1.3.1" and fr.lirmm.graphik:graal-io-dlgp:1.3.1 (and their dependencies)

Database starts out with 107 facts and 180 rules and after saturation has about 1450 facts.

I'm trying to track down why I'm getting fewer facts with graal than with my previous solution. I think I've narrowed it down to rules like the below.

precedes(O1,O2) :- precedes(Sk2,Sk1),Sk1 = O2 ,temporallyProjectsOnto(O1,Sk2).

It's a stupid use of =. While a person wouldn't write these rules, the process that generates them is more stupid and currently does.

I could fix the rules by doing the = substitution as pre-process

precedes(O1,O2) :- precedes(Sk2,O2),temporallyProjectsOnto(O1,Sk2).

I may land up doing that to detect (effectively) duplicate rules. But still, it would be good to know if this is a known issue/expected behavior or bug.

Thanks

Hi, I got an exception error when performing query answering using RewritingOnly for appraoch and RDF4j store for data. The version of each component is 1.3.1.

The error occurs in RDF4jUtils.atomToStatement, the message says "arity 1 is not spported by the store"
I looked into the code and it confused me why assertions of arity 1 can not be created into a statement.

When parsing the Atom "predicate(X)" with DlgpParser.parseAtom, the result is "predicate\1(I0)". I would expect it to be "predicate\1(X)". Is there a reason why the variable name is ignored, or is this a bug?

Relating, sort of, to #5, I had another thought:

If the KB is able to be told the unique name assumption holds in a particular case I think it could be very little work to support equality/inequality testing in rule body. I'm thinking this because you wouldn't have to add new structures to manage equality in general as equality/inequality is completely determined and easily testable in that case.

It would still be worth signaling an exception if equality is asserted in the head, since there more issues there (I imagine).

At least in my case, this would be quite useful gain in expressivity. I think it is the common case that unique names are assumed, so the increased expressivity could benefit other as well.

I guess I could manage this myself via using pseudo equality/inequality predicates and adding the extra assertions to any kb I have, and I may do that, but thought it was worth a mention.

Hello everyone,

I am currently writing on a module for VLog4J that would allow it to convert Graal objects and DLGP-files for use by our existential rule engine.
While working on the DLGP-files, I noticed that the second example in the DGLP documentation throws parse exceptions.
What I did: copy the contents of example "An example which illustrates the use of IRIs and literals" into a file, load it into the parser with new DlgpParser(new File("file.dlp")) and iterate over it with parser.hasNext() and parser.next(). I get a parse exception directly at line 0 column 0.

The following scenario does not work:

• get a query: ?(X,Y) :- p(X,Y).
• rewrite it with the following rule: p(a,Y) :- q(Y).
• you should get a rewrite : ?(X,Y) :- q(Y), X = a.

We should be able to query all kinds of Store.

I see that DefaultInMemoryGraphStore is deprecated. Maybe somebody could appoint me to easy use alternative ? In memory, without any databases.