Support for different domain models

[mike1813]

At present, every domain model contains a property core#domainGraph whose value is a URI that distinguishes the domain model from other domain models. When deployed to a system-modeller instance, the domain model is saved in the triple store at a graph with that URI.

When a system model is created, one must select which of the deployed domain models it will be based on. This is saved as the property core#domainGraph of the system model resource (the one representing the system model*). Its value is used subsequently by system modeller to find the correct domain model in the triple store.

The core#domainGraph reference used in domain and system models does not include version information, so it can refer to any version of that domain model. Each domain model also has a owl#versionInfo property giving this information as a string, which is also copied to the system model core#domainVersion property by the system modeller when the system model is validated.

These features of our current set up creates several problems which should be addressed.

• It is not possible to deploy multiple versions of the same domain model to a system modeller instance because they are all stored in the same graph. The previous version is overwritten when a different version is uploaded. This is a problem if some system models need to continue using the previous version.
• When a system model is created, in addition to setting the core#domainGraph URI, the core#domainVersion string should also be set, so this is available as soon as the system model exists, even before it is validated.

The graph URI where a domain model is stored should be distinct for different versions of the same domain model. This should be used as the value of the core#domainGraph property in a system model created from that domain model. It should also be determined from the domain model core#domainGraph and owl#versionInfo properties, so the same URI is used for the same domain model and version by two different system modeller instances. In that way, that same URI can be found for any system model from its core#domainGraph and core#domainVersion properties, and the result will make sense if the system model was exported from one system modeller instance and imported into another.

If we could deploy multiple versions of a domain model to a system-modeller instance, and refer to a specific version in the system model core#domainGraph property, then:

• It should be possible to manually change the domain model (i.e., the core#domainGraph property) after a system model has been created. System modeller should indicate (e.g., using a drop down list) which alternative models are available.

This is already a problem if we have variants of a domain model for different projects (e.g., with different optional features included). For example, we might have two distinct domain models (not different versions of the same model) such as 'domain-network', and a variant that contains some extra features for a specific project, e.g., domain-network-nemecys may have an extra patient harms submodel. It is not possible to create a system model based on one of these, then switch to the other domain model in system modeller. At present the only way to do this is to export the system model NQ file, manually editing the core#domainGraph property, and reimport.

• It should be possible to manually change the domain model version (i.e., the core#domainVersion property) after a system model has been created. System modeller should indicate (e.g., using a drop down list) which alternative versions are available.

This is obviously necessary if a system model core#domainVersion property refers to a specific version, and one wishes to upgrade. In addition, we need an automatic selection in some situations:

• It should be possible to manually specify that the domain model version (i.e., the core#domainVersion property) be set to the latest available version without needing to search a list of versions and select this.
• If a system model had a core#domainVersion property not available on system when validated or revalidated, this property should be automatically updated before starting the validation process.
• If a system model had a core#domainVersion property not available on system when risks are recalculated, this property should be automatically updated and then the model revalidated before starting the validation process.

The first of these is just a convenience features, allowing system modeller to decide which version you want. Since revalidation is a slow process, in the last case the user should be given the chance to cancel the risk calculation instead.

• It should be possible to specify that a system model should automatically switch to using the latest available version of its domain model when it is revalidated, even if the core#domainVersion property specifies a version that is available.
• It should be possible to specify that a system model should automatically switch to using the latest available version of its domain model when risks are recalculated, even if the core#domainVersion property specifies a version that is available.

These two features are to allow system models to be created that are expected to continue working with the latest version of a domain model. We need to specify this separately for validation and risk calculation because updating the domain model version means system modeller will need to revalidate and that is a time consuming process. Risk calculation is supposed to be fast, so it should be possible to specify auto-update for validation but not risk calculation.

The auto-selection features (the one click manual upgrade) and auto-upgrade features will need some care. Old system models are not guaranteed to work with new versions of domain models. the domain model version info is supposed to give some indication whether this is the case. We may need different options allowing automatic upgrade to the latest version installed on that system modeller, or the latest version known to be compatible with the system model.

Finally, if no domain model version is available that meets whatever criteria are used, system modeller should handle it without crashing. At minimum, it should tell the user about the problem, and maybe provide a link to do a fully manual domain model or version change.

* At present there are two such resources, due in part to a mix up on what these resources are and how they can be made referenceable. See #69 and #195. The same problems also affect the domain model resource. Here I am assuming that problem will be fixed, so there will be one resource in each system (or domain) model whose properties relate to the whole model.