SEMICeu / style-guide

SEMIC style guide to create reusable vocabularies and application profiles
https://semiceu.github.io/style-guide/
Creative Commons Attribution 4.0 International
9 stars 2 forks source link

Chapters 7.9, Abstract classes + 7.17 Element stereotypes #76

Closed RiittaA closed 1 year ago

RiittaA commented 1 year ago
csnyulas commented 1 year ago

I don't hink that rule 7.9 ("CMC-R9: Abstract classes Identifier") and 7.17 ("CMC-R17: Element stereotypes") are in conflict.

CMC-R9 says that "Classes that are not intended for instantiation can be marked as abstract." and in the description it explains that models often identify classes that are not supposed to be instantiated (i.e. directly) and are declared as a superclass for more concrete subclasses, which are to be instantiated. Such "abstract" classes are useful mainly for organisational purposes.

In this rule we also recommend declaring such classes as "abstract" using stereotypes, and, in fact, we even provide a link to the "stereotypes" rule (CMC-R17), which says that "Stereotypes do not have semantic or normative value. They shall be avoided in the conceptual models unless a good motivation, and a strong need is provided." So, the main point of this rule is about the interpretation of the stereotypes. It also recommends stereotypes not to be used, if possible, but it also clearly states that exceptions are allowed, when there is a good use case for them, and in the description it specifically talks about the <<abstract>> stereotype, which is a useful one.

Of course the observation that the concept of "abstract classes" is not a coherent one, especially in the context of OWL, is a perfectly valid one. In fact OWL doesn't even deal with such concept. However, as we also say in the CMC-R9 rule's description, although the concept of abstract class may not have any relevance to the generated OWL artefact, it can be very useful for the generation of the SHACL artefact. Here is the relevant quote from the rule: "Doing so has no impact on the OWL 2 [owl2] representation of the model (as this cannot be expressed in OWL). However, depending on the toolchain implementation, SHACL data shapes [shacl] can be generated to express that no instances of this class shall not occur in the data."

Do you agree with this @RiittaA ?

I would like to close this issue, unless someone can provide a concrete suggestion for how we can improve the Style Guide to address this issue. The most I could suggest we could do, is to change the rule's statement from: "Classes that are not intended for instantiation can be marked as abstract." to: "Classes that are not intended to be instantiated directly can be marked as abstract."

Would this be an improvement? @costezki, @RiittaA, or anyone, has a better idea?

RiittaA commented 1 year ago

@csnyulas @costezki, Thank you for the reply. I think that changing wording of the statement as you suggested is ok. So you can close the issue.

csnyulas commented 1 year ago

Closing this as it has been addressed as agreed.