Weird behavior when making profile of "removed" SGOV class

[RadStr]

The issue

When profiled class from SGOV is "removed", meaning undoing expansion of class in whose surrounding's the class lies. The profile no longer shows that it is profile, since the profiled class is no longer present.

How to replicate:

1. Open CME https://tool.dataspecer.com/conceptual-model-editor
2. Click Add new vocabulary
3. Click on Well-known vocabularies tab
4. Select Czech Semantic Dictionary of terms
5. Go to classes tab
6. Click ❌ Expand on Natural person
7. Create profile of Human with 🧲 The result should look like this:
8. Click ✅ Expand on Natural person The result should look like this:

One of possible solutions:

Profiled SGOV entities are always present in the catalog, even after the removal of surroundings of source class.

[sstenchlak]

If you consider the model hierarchy with SGOV at the top (as the source of existing classes) and your own model at the bottom (as something you are working on), the SGOV model should not depend in any way on the models below.

Of course, you can inform the user that removing a class will break the model, and you can try to prevent them from doing that or implement your proposed solution. However, in theory, due to the hierarchy, it may happen that any model at the top introduces changes that break the models below.

This should be handled through an evolution process (which is work in progress):

• The source model introduces a sequence of changes, effectively transitioning from version A to version B.
• The dependent model, which relied on version A, needs to react to the changes made between A and B and properly update itself to regain consistency. Some changes can be processed automatically, while others require user input, such as confirmation (in cases where the change would result in the deletion of something) or a decision (for example, whether to delete the dependent entity or make it independent).

In this case however, since you aim to make the process as simple as possible and both models are in the same specification, your solution is viable.

By the way, it would be great if the tool remained robust. This means that if there are inconsistencies or errors in the models (associations without an end, attributes without a class, etc.), the user should be informed about them but still be able to work with the model within reasonable limits. (i.e., the application should not crash)