Proposed changes to the classification wrapper to support new Drug Model
Problem:
In order to properly express what drugs are used for, we need to be able to express the 'Role' that they can play. Some NRCs will want to use these roles and others will not, as the additional attributes will cause modelling issues. Moving the additional roles into a new module would allow them to be included or filtered out as required.
These roles are additional definitions which, while true, are not part of the set of sufficiently defining conditions. The existing code for converting RF2 to OWL for classification - as it stands - puts all attributes into a single axiom, which would effectively including the roles in the sufficient set ie the fully defined definition, when we don't want them to. This is a problem because concepts that do have the sufficient set of defining attributes will no longer subsume under that concept if they don't also have the 'role' attribute.
We need to be able to support an aspect of EL called "Multiple Sufficient Sets" which is where you have your fully defined criteria, and then, separately, there are additional criteria which (if not fully defined) are not required to be present for a concept to be properly subsumed.
Proposed Solution:
The suggestion is to modify the classifier wrapper so that it collects relationships coming from different modules into separate axioms. This will give us the "Multiple Sufficient Sets" functionality that is required to prevent unwanted subsumption issues. This behaviour is actually how other OWL environments - like Protégé - work.
There is some overlap with the work being done currently by the Modelling AG which should also provide this functionality, but the proposed solution is an improvement to the current OWL transformation to bring it into line with accepted OWL practice. Also the Modelling AG work is an unknown time off implementation, and whereas this solution removes a blocker to Drugs work proposed for 2017.
Please send me your thoughts and comments as always - thanks,
Comments
Hi,
My current impression is that it is a simple fix for one use case, but it will make many other RF2 use cases (that are not mentioned in the proposal) really complex. However, I need to think more about it before I have a more well-grounded opinion.
(Would a better idea be to investigate if the use case is possible to solve by adding more attribute values to the relationship attribute characteristicTypeId?)
Regards
Mikael
Hi,
My current understanding is still that this is a quick and simple fix for one use case, but it will make many other RF2 use cases really complex (as also @Dion McMurtrie presents above), because the module functionality wasn't designed to do this when RF2 was created. I therefore wonder if there had been any investigation of the potential drawbacks of the proposed solution or any investigation of alternative solutions.
Regards
Mikael
As I understood the proposal the set of stated relationships with a given module id would be considered a sufficient set. So
Rel
Module
1
A
2
A
3
B
would be considered 2 sufficient sets
1 and 2
3
There's a few implications of this to consider.
what does this do to the family of languages work and structural subsumption currently in use (I'm not sure what is out there.
you've got a provision for multiple sufficient sets but you've not got the ability despite doing this to represent also necessary conditions which aren't part of a sufficient set.
what about extensions? This would make it impossible to add conditions to the sufficient set/s defined in the upstream edition being extended.
you also need a module per sufficient set to achieve this, so if you have concepts with a number of sufficient sets this may cause creation of modules just to facilitate each additional sufficient set which is a bit ugly.
what do you do if two stated relationships have different module id but the same role group, would that become illegal?
Perhaps an alternative might be to create a reference set which can reference relationships indicating which sufficient set they belong to for their source concept (use a UUID or something). But that would create a big reference set immediately for all existing stated relationships even where no additional sufficient sets exist, so I understand why this isn't appealing. It would, however, resolve the module proliferation required to support a number of sufficient sets and the concerns about extensions. You could engineer a solution to necessary but not sufficient conditions coexisting with sufficient sets but that may confuse the role of the primitive flag in the concepts file.
Otherwise I can imagine that absorbing this change isn't a massive problem for authoring tools.