This content has been marked as final. Show 1 reply
As you observed, the rules index is not updated every time a triple is added. The create_entailment procedure has to be explicitly called to update the rules index. This is for performance reasons, and our recommendation is to call the create_entailment procedure after some updates have been made, for example, on a nightly basis.
But this does not meant that semantic data cannot be queried before the rules index is updated. When new triples are added, the rules index goes into an 'INCOMPLETE' state (to indicate that there could be new triples that can be inferred, but that that has not happened yet), and SEM_MATCH can be used for query, provided 'INCOMPLETE' is passed in as an argument (see section 1.6 in the documentation for details). Similarly, when triples are deleted, the rules index goes into an 'INVALID' state (to indicate that some of the inferred triples might not be valid any longer), but SEM_MATCH can still be used, by passing in 'INVALID' as an argument. This functionality enables a user to continue querying semantic data but ensures that the user is cognizant of the fact that the triples have been added or deleted and hence the rules index status has changed. In other words, the user has to explicitly pass in 'INCOMPLETE' or 'INVALID' to indicate that he or she is OK with the results being so.
The inferred triples are stored in internal tables, and can be viewed using the view SEMI_<rules_index_name>. You do not have to worry about the same relationship being inferred every time, create_entailment is optimized to handle all that. If you want to store triples inferred through other means, then we would recommend using a model (like with the original set of triples; the same model could also be used).