Filtering in the link palette generation

[mike1813]

The link palette consists of a JSON stanza containing lists of the possible relationships that could be added by a user. The palette data is used in the system modeller GUI to decide which relationshiptypes the user will be offered when they try to create an asset relationship.

The palette generation used to be very time consuming because it used an over-complex SPARQL query based on an overspecified set of restrictions. This has been fixed, but as a result there are fewer restrictions and some links are returned that shouldn't be offered to users by the GUI.

Each relationship type is currently defined as an owl:ObjectProperty, with properties core:hidden and core:isAssertable specifying whether the relationship type should be displayed in the GUI, or made available when creating an asserted relationship. Currently, the link palette generator uses a SPARQL query that returns the value of core:hidden, but does not filter on it.

In addition, it should not be possible to add a relationship unless it connects two 'concrete' assets, i.e., assets that are either assertible or inferred by construction patterns. At present, the link palette data contains entries in which one of the asset types is not concrete.

Ideally, filters would be added to the SPARQL query so the superflous entries are not created.

[mike1813]

The query now used by the link palette generation (after merging changes from branch 104) is:

	String query = "#Retrieve all relations and their domain and range\n" +
			"PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>\n" +
			"PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>\n" +
			"PREFIX core:<http://it-innovation.soton.ac.uk/ontologies/trustworthiness/core#>\n" +
			"PREFIX owl:<http://www.w3.org/2002/07/owl#>\n" +
			"SELECT DISTINCT ?from ?prop ?label ?comment ?to (STR(?hidden) AS ?isHidden) WHERE {\n" +
			"	?prop a owl:ObjectProperty .\n" +
			"	?prop rdfs:domain ?domain .\n" +
			"	?prop rdfs:range ?range .\n" +
			"	?prop rdfs:label ?label .\n" +
			"	?prop rdfs:comment ?comment .\n" +
			"	?prop core:hidden ?hidden .\n" +
			"	?from rdfs:subClassOf* ?domain .\n" +
			"	?to rdfs:subClassOf* ?range .\n" +
			"} ORDER BY ?prop ?from ?to";

There are three sub-issues to be addressed here:

• Which property (core:hidden or core:isAssertable) should be used to signify whether the relationship type is assertible?
• How should the query be modified so it uses whichever property is chosen to avoid returning non-assertible link types?
• How should the query be modified so it doesn't lead to link palette data involving non-concrete source or target asset types?

The property that was supposed to specify whether a relationship type is assertible is core:isAssertable, but since 'hiding' a relationship in the GUI would make it impossible to assert it, this was mistakenly used instead. This query does return the value of core:hidden, and it is possible this is used elsewhere in system-modeller, so that shouldn't be changed without checking for possible side effects.

Whichever property is used, it should be easy to filter on its value. WIth the current query, we can bind ?hidden to be 'false' and thus exclude results involving a relationship type specified as 'hidden'. If we switch to core:isAssertable, we would need to bind its value to be 'true'.

Filtering out asset types that would otherwise be returned as the ?from and ?to variables is much more difficult. Relationships should be in the palette if both ends refer to asset classes that are 'concrete', meaning they can exist in a system model. This can only occur if:

• the asset class is assertible, in which case a user could insert it into a system model via the asserted graph, or
• the asset class is created by at least one construction pattern, in which case it could be added by inference based on the presence of other assets and relationships, and
• the asset class is not 'construction state', as in that case it is used in construction patterns only to carry state information between patterns, and should normally be removed at the end.

The first case is covered by the core:isAssertable property of each domain model asset class, which is 'true' if the asset class is assertible. The last is covered by the property core:isConstructionState, which if present and set to 'true' means the asset class should be deleted at the end of the construction pattern sequence. However, there is no property that encodes whether an asset class can be created by a construction pattern. To find that we would need to query the construction pattern structures, so it would be quite complex.

Recommendation: do nothing about this issue unless it causes problems, i.e., we find users are tempted to assert relationships they shouldn't, or getting confused by extra options that shouldn't be visible. If that happens, we should try to fix it by excluding non-assertible relationships in the first instance. Only if absolutely necessary should we attempt to restrict the link palette to relationships to and from concrete asset classes.

[mike1813]

Reviewed by @mike1813 : this is a bug but it is not a very important one. If nobody is complaining that they are seeing too many inexplicable relationship types, then we should leave it until they do.