Validator fails to store some inferred links

[mike1813]

The attached system model was created as a test case to use while addressing issue #44. The test contains a single Sensor asset called 'Sensor'. The construction pattern sequence then adds 6 inferred assets:

• [World] is the global inferred public space where the Sensor is assumed to be (given that it has no other location)
• [Data:Sensor] is the sensed data
• [SensorProcess:Sensor] is the onboard process that communicates this data to other processes
• [OutputPool:[Data:Sensor]-[SensorProcess:Sensor]] represents the data in the workspace of the process
• [HostContext:Sensor-[World]] is the context for access rights on Sensor when in [World]
• [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]] is the context for access rights of [SensorProcess:Sensor] on Sensor when in [World]

There is no stored copy of [Data:Sensor] because the domain model used doesn't assume sensor output is stored on the sensor. The plan was to add a Sensor-stores-[Data:Sensor] relationship and use that as a test case for issue #44.

The baseline test was to validate without this extra relationship, but that did not produce the expected output. Specifically, the inferred relationships should be:

• [OutputPool:[Data:Sensor]-[SensorProcess:Sensor]]-usedBy-[SensorProcess:Sensor]
• [OutputPool:[Data:Sensor]-[SensorProcess:Sensor]]-usedFor-[Data:Sensor]
• [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]]-accessFrom-[World]
• [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]]-accessTo-[SensorProcess:Sensor]
• [ProcessContext:Sensor-[SensorProcess:Sensor]-[World]]-accessTo-Sensor
• [HostContext:Sensor-[World]]-accessFrom-[World]
• [HostContext:Sensor-[World]]-accessTo-Sensor
• [HostContext:Sensor-[World]]-propagatesTo-[ProcessContext:Sensor-[SensorProcess:Sensor]-[World]]
• [SensorProcess:Sensor]-creates-[Data:Sensor]
• [SensorProcess:Sensor]-enablesAccess-[OutputPool:[Data:Sensor]-[SensorProcess:Sensor]]
• Sensor-hasPhysicalHost-Sensor
• Sensor-hosts-[SensorProcess:Sensor]
• Sensor-locatedIn-[World]

In fact, all the CardinalityConstraint entities were created as expected, but the source asset properties referring directly to the target asset were not, except for the last three cases in which the source asset was asserted.

This is a serious issue, as it means subsequent inferences may fail in some situations.

[mike1813]

Attached test case is here, without the extra link having been added.

Issue 44 Test - Asserted - Before.nq.gz

[mike1813]

Turned out the problem was in the JenaQuerierDB.sync() method, which cached changes to the triple store. It must write Assets before CardinalityConstraints, or the Asset sync will overwrite properties of the Asset not in the cached AssetDB - i.e., the property directly encoding the asset-asset link.

The reason this didn't cause very obvious problems before now is that the order in which entities are synched is arbitrary, and is left to the Java HashMap implementation. I suspect this behaves like a FILO, so if the first AssetDB is cached before the first CardinalityConstraintDB, then the CardinalityConstraintDB entities will be cached before the AssetDB entities. I think this only happens if the system model contains no asserted links at all, which of course isn't usually the case.

The clue to this was that the problem goes away if even one asserted link is present.

Code now fixed on branch 44, linked to this issue. Further work is needed on this branch to complete the changes needed for issue #44, so not yet included in any pull request.