Open mike1813 opened 1 year ago
@kenmeacham : some notes following our conversation.
In any recent release on branch v6a, every assertible asset (core#isAssertable = true) has a parent that is a subclass of core#PaletteType. Right now:
The resource core#PaletteType is currently NOT included in the core model definition in the system modeller code base (core.rdf). I guess that will need to be added. It is NOT a subclass of core#Asset. It is in effect a sibling of core:Asset, so we could do worse than make it a copy of core#Asset with a different URI.
Once that has been done, it should be possible to look for direct subclasses of core#PaletteType to make into palette groups, instead of looking for direct subclasses of core#Asset. All direct subclasses of core#PaletteType in recent domain models:
At present, there seems to be no tool tips attached to palette groups, so there is no need to use the rdfs#comment property for that purpose. It is just something you could do if you felt like it.
I have adjusted the query that gets the palette assets to use core#PaletteType. This seems to work fine, and the GUI now groups the assets in the palette accordingly. The following screenshots show a before / after. You can see that the asset groups are now defined by the palette type. In this example, the Juristiction asset has now moved into the "Users and Governance" group:
Before fix:
After fix:
The resource core#PaletteType is currently NOT included in the core model definition in the system modeller code base (core.rdf). I guess that will need to be added. It is NOT a subclass of core#Asset. It is in effect a sibling of core:Asset, so we could do worse than make it a copy of core#Asset with a different URI.
I have added PaletteType to the core model as follows.
<owl:Class rdf:ID="PaletteType">
<rdfs:subClassOf>
<owl:Class rdf:about="#CompositeThing"/>
</rdfs:subClassOf>
<rdfs:comment>Defines a group of assets in the GUI palette.</rdfs:comment>
<rdfs:label>PaletteType</rdfs:label>
</owl:Class>
@mike1813 - Does this seem correct, to make this a subClass of #CompositeThing?
Once that has been done, it should be possible to look for direct subclasses of core#PaletteType to make into palette groups, instead of looking for direct subclasses of core#Asset. All direct subclasses of core#PaletteType in recent domain models:
* have a rdfs#label property that can be used as the title of the palette group (in the same way as we do for subclasses of core#Asset) * has an rdfs#comment property that can be used as a tool tip explaining the group, if desired.
At present, there seems to be no tool tips attached to palette groups, so there is no need to use the rdfs#comment property for that purpose. It is just something you could do if you felt like it.
I considered this, however this would mean restructuring the palette returned to the GUI, as we currently don't include the description (comment) for any "category". Furthermore, the contents don't seem so useful at the moment anyway, e.g.
<http://it-innovation.soton.ac.uk/ontologies/trustworthiness/domain#DataPalette> <http://www.w3.org/2000/01/rdf-schema#comment> "An overlay parent class descended from Palette Type, to be used to control the grouping of assertable assets in the SSM GUI Asset Palette." <http://it-innovation.soton.ac.uk/ontologies/trustworthiness/domain-network> .
At present, the palette of asset types displayed in the system-modeller editor window is created by finding the subclass of
core:asset
of which each assertible asset class is a descendent. This subclass ofcore:asset
is taken as the palette category in which to display the asset type in the palette.This means that (for example) every type of Host must be displayed together in the Hosts palette group, every Process in the Processes palette group, and so forth. That isn't always the best option.
For example, the domain-network submodel for Cloud Management currently uses specialised Host subclasses to represent Kubernetes Master, Worker, Pod and Container components, Process subclasses for the Kubernetes API Server and Ingress proxy, and a NetworkAsset subclass representing the ClusterIP overlay network between the Master VM and running Pods. Ideally, those asset classes would be in a separate 'Cloud' group.
The domain model does contain a mechanism to handle this. Alongside the asset class hierarchy descended from
core:Asset
there is a separate 'overlay' hierarchy descended fromcore:PaletteType
. So setting?category rdfs:subClassOf core:PaletteType
would provide a means for the domain model to specify a palette grouping based on any criterion.At present, each assertible asset has only one palette 'category'. That restriction can be respected by domain modellers at least to begin with. Later, we may want to allow each asset to appear in more than one 'category', but this may require more extensive changes, so can be left as a separate issue.