Support for modular domain models

[mike1813]

Domain models are composed of elements each of which is now assigned to a specific package. This was introduced so a canonical ordering could be defined for each CSV table, where rows are sorted by package, then by the URI of the associated entity, and then by other fields as necessary. The CSV tables are supposed to be in this order when committed to GitHub.

The original reason for doing this was to ensure that rows associated with specific parts of the domain model would be kept together in the CSV tables. Changes in one area (e.g., the sub-model for physical spaces) would then not overlap with changes in another area (e.g., the sub-model of IoT devices). These changes could therefore be made at the same time (perhaps by different people), and merged easily by Git. This is needed because (unlike most other programming languages), we cannot have one file per sub-model as it would then contain different types of entities.

Until recently, this approach failed for table ConstructionPattern.csv, because construction patterns form a sequence, and the only logical ordering for that table was to follow the sequence. However, this has now been replaced by a partial sequence defined in terms of CP dependencies (see #169).

It now makes sense to introduce support for more modular domain models. Specifically, it should be possible for a domain model to be generated for subsets of the domain model packages. There are several steps:

• Check if it is possible to omit packages on which no others depend without causing any inconsistencies, i.e., verify that the CP sequencing issue Modularisation and Construction Pattern Sequencing #169 was indeed the only remaining barrier preventing this.
• If we can omit packages safely, add a table (or a field in an existing table) to specify which packages should be used in a given build.
• Introduce a filtering option that can be used in csv2nq to instruct it to use only the specified packages.

This would mean that each future commit in GitHub will include a specification of which packages to use for that commit. Either the filtering option is switched off (so all packages are used), or it is switched on and the package selection table/field used to determine what is mapped to NQ.

This would make it much easier to create releases for specific projects or purposes. We would have one development branch in GitHub that includes everything and has a default set of packages selected, e.g., it may have sector-specific packages switched off, and where a submodel has alternative implementations, the latest or most sophisticated would be selected. To develop the sub-model in a specific package, we create a branch where that package is selected, irrespective of whether it is one of the default selections. If a release including this package is needed for some purpose, the release can be made once everything is working. Then a final commit on that branch would restore default selections so all the changes can be merged back into the main development branch.

It may be necessary to add some package consistency checks in csv2nq or in the domain model editing tools to check there are no selected packages that depend on any deselected package. If found, this should either automatically select the required package or cause an error in NQ file generation, the latter being the only option if there are alternative packages that could fulfil the missing dependency.