TWALocations table may be redundant

[mike1813]

TWALocations.csv encodes which Asset classes have each TrustworthinessAttribute. Each row contains:

• a TrustworthinessAttribute URI
• an asset class URI, specifying an Asset class all of whose subclasses (including itself) has the attribute
• a package URI determined from the dependency hierarchy

The package URI is the one to which either the TWA or the Asset class belongs, taking the one highest up the interdependency stack. This allows a TWA introduced as part of (say) the network submodel applying to all Hosts to be applied to assets like IoT Things - rows in TWALocations.csv that refer to Thing asset types would be in the IoT package, while those referring to generic Hosts would be in the network package.

Why is this information redundant? Because every TWA is undermined by an associated Misbehaviour, as defined in TWIS.csv. This means each TWA can only be present at assets having the associated Misbehaviour, so the TWA Locations must be a subset of the Misbehaviour Locations.

It is possible for a Misbehaviour to exist with no associated TWA, and in principle it is possible for this to be the case for some assets and not others. Hence TWA Locations forms a subset of the Misbehaviour Locations. However, every domain model (and system modeller) to date has assumed that if a Misbehaviour has an associated TWA (i.e., the Misbehaviour has a TWIS.csv entry), then the associated TWA will exist at every asset having the Misbehaviour. That is to say, it has always been assumed that TWA Locations and Misbehaviour Locations are identical.

If that assumption remains valid, then we shouldn't have a separate TWALocations.csv source file. They should be derived from TWIS.csv and MisbehaviourLocations.csv, ensuring TWALocations.csv and MisbehaviourLocations.csv are always consistent. Consistency can always be checked by the Access DB system model editor, but this is not useful if anyone edits the files by some other means.

Recommendation: do nothing right away, but keep this as an open issue which should be revisited if either (a) we decide the two tables should always refer to the same set of assets (i.e., the previous assumptions will never be dropped), or (b) people start using other tools for domain model editing that don't have any built in consistency checks.

[mike1813]

Obviously, if we remove TWALocations as a separate source file, then either (a) csv2nq and possibly other tools like csv2doc would need to generate it from the TWIS and MisbehaviourLocations tables, or (b) it would need to be removed from the domain model NQ encoding produced by csv2nq and system-modeller modified to work without it.