some rules may content rule head triplet

[meloncolie]

@lajus
There are some notable rules may content rule head triplet when setting max length of rule to 4 and running on the dataset YAGO15K (may could be recurrented on any YAGO data with wasBornIn/diedIn). For instance,

?m  hasNeighbor  ?b  ?g  wasBornIn  ?a  ?g  wasBornIn  ?m   => ?a  hasNeighbor  ?b      0.14893617      1.0     1.0     77      77      77      ?b

Since any head of wasBornIn only has a single tail (nobody is born in two place at same time, and also be check on YAGO15K), ?a must be identical to ?m. Thus, the ?m hasNeighbor ?b term in rule body can be rewrite as ?a hasNeighbor ?b, which is literally the rule head. It should not be considered as a rule, in other word, this rule should be deleted.

By the way, is it possible to save the predict instances (including nodes in each predict) of each rule? Therefore, anyone can check the correctness of rules.

[lgalarra]

Hi,

I almost certain that in such cases AMIE includes a differentFrom condition on those variables, i.e., differentFrom(?m, ?a), see line 351 in the default mining assistant: https://github.com/dig-team/amie/blob/master/mining/src/main/java/amie/mining/assistant/DefaultMiningAssistant.java

However the display method for rules omits those atoms as we can see here: https://github.com/dig-team/amie/blob/010bf090dafc58577dcac5448e5349098cc957f3/rules/src/main/java/amie/rules/Rule.java#L1392

Best,
Luis

[meloncolie]

I have tried my best to unterstand those code, but it's pretty hard for me to read these complex classes and java language. Could you please show me how to print the the support/predict instances.

Thank you,
Bin

[lgalarra]

Hi Bin,

I am intrigued. Could you please verify that there are not reflexive triples X hasNeighbor X? Otherwise, could you send me the YAGO15K file to test what is going on?

Best,
Luis

[meloncolie]

Hi Luis,

I have verified that there's no relfexive relationships with the codes in below. Glad to send you the tsv file as an attachment. The wired rules are appeared when run program with the argument -maxad 4 yago15k_edges.tsv .

In [7]: df = pd.read_csv('yago15k_edges.tsv', sep='\t', names=['s', 'p', 'o'])

In [8]: df[df['s']==df['o']]
Out[8]: 
Empty DataFrame
Columns: [s, p, o]
Index: []

yago15k_edges.zip

Best,
Bin

[meloncolie]

Hi Luis,

Have you reproduced or fixed the problem?

Best,
Bin

[lgalarra]

Hi,

I am overwhelmed at this moment. I may have some time to look at it next week. If you do not hear from me, feel free to send me a reminder please. Sorry for the delay!

Best,
Luis

[meloncolie]

Hi,

I am overwhelmed at this moment. I may have some time to look at it next week. If you do not hear from me, feel free to send me a reminder please. Sorry for the delay!

Best, Luis

Thanks for your response! OK, I am looking for your good news next week.

Best,
Bin

[lgalarra]

Hi Bin,

Question, which version of AMIE did you use? I ran

$ java -jar amie-milestone-intKB.jar -maxad 4 yago15k_edges.tsv

but could not find the rule you reported. The jar file is among the release files provided in this repository.

Best,
Luis

[meloncolie]

Hi Bin,

Question, which version of AMIE did you use? I ran

$ java -jar amie-milestone-intKB.jar -maxad 4 yago15k_edges.tsv

but could not find the rule you reported. The jar file is among the release files provided in this repository.

Best, Luis

Hi Luis,

I used the master branch and have run your command, the result is correct. I noticed that the problem only occurs when man runs amie-dev.jar in the root directory. What is the different between amie-dev.jar and amie-milestone-intKB.jar?

Best,
Bin

[lgalarra]

The amie-milestone-intKB.jar is the version that was used for the experiments of the AMIE3 paper.. so it is sort of a stable version. I checked all the changes that came afterwards: milestone-intKB...master, so it seems we are facing a bug introduced by our improvements.

[meloncolie]

The amie-milestone-intKB.jar is the version that was used for the experiments of the AMIE3 paper.. so it is sort of a stable version. I checked all the changes that came afterwards: milestone-intKB...master, so it seems we are facing a bug introduced by our improvements.

OK, btw, could you implement recording all instances(including all nodes on each path) of each rules to a file. Thanks