One of the reasons I need graphs in my ifpstore is that at work I have an application that needs to ensure it is getting its security information from the right source. It uses a store aggregated from multiple sources for its data, and so without graph-matching, any of the other sources could theoretically add a ('joeBloggs memberof superusergroup') triple to the mix and subvert the security.

The problem is that my store also supports SIA, IFP and subproperty/class inferencing. This opens up a whole new can of worms, because (again theoretically) one of the sources could add a triple that affects the inference (e.g. 'isMemberOf rdfs:subPropertyOf isAdministratorOf' springs to mind).

The best solution to this I can think of is to have a special trusted graph set aside to hold triples used for inferencing. The import mechanism would then copy trusted schema statements that affect inferencing to this graph.

The approach would add another constraint to each back-chained inference (i.e. statement has to be in the trusted graph).

Hmmm.. an alternative spin would be to have a seperate table for the trusted inference statements. Am not sure which would be quicker (because caching plays such a large part as the size of the store scales up) - would have to profile with a large store.