OntoUML icon indicating copy to clipboard operation
OntoUML copied to clipboard

Kind is not abstract in {disjoint, complete} SubKind example(s)

Open davidstraka2 opened this issue 5 years ago • 6 comments

The name(s) of the abstract entity/entities are missing cursive. See EX2 in SubKind examples on (GitHub, Read the Docs).

davidstraka2 avatar Nov 20 '20 07:11 davidstraka2

I didn't understand your question. Do you mean that Normative Act and Decree must be declared as abstract to be consistent with the complete generalizations below them?

claudenirmf avatar Sep 30 '21 15:09 claudenirmf

@claudenirmf Yes exactly, Normative Act and Decree.

davidstraka2 avatar Sep 30 '21 20:09 davidstraka2

This is an interesting discussion, actually, because the "abstract" and the "complete generalization" constraints related but refer to different things.

I would wait a little bit before making this change because there may be a constraint to be added. Still, there are implications to it, for instance for model reuse and for modeler's intended representations.

claudenirmf avatar Oct 01 '21 07:10 claudenirmf

@claudenirmf while it is actually different things (you can have concrete instance of Decree of indeterminate type), question is whether this must be expressed in a conceptual model. I would personally enforce it to be abstract if a complete partition is defined in the conceptualisation while this can be relaxed in the logical/physical models.

tdebodt avatar Nov 24 '21 19:11 tdebodt

@tdebodt consider the situation where I build some reference ontology, let's call it Software Issue Ontology, where I have the concrete kind Throwable. Later, someone decides to extend my ontology creating the Java Software Issue Ontology, where two subkinds are added to it in a {disjoint,complete} generalization set, Error and Exception. If we require that in the extension of the original ontology Throwable is declared as abstract, this would be a "change" on the reference ontology.

One could argue that the generalization set should be incomplete in this example, but that is not my point. My point is that I am very cautious about forcing changes on reused resources. Even though the {complete} constraint alone is already a sort of change on the semantics of Throwable, at least it is declared on a model element that is not part of the Software Issue Ontology.

Either way, I cannot settle right now on how to approach this issue, specially considering that not declaring abstract classes as such may hurt the understanding of the ontology through "partial views" (i.e., diagrams) of the whole model. I admit that for now I feel divided on this issue.

claudenirmf avatar Nov 25 '21 10:11 claudenirmf

IMHO, Normative Act and Decree in the example are indeed abstract classes.

The current specification defines the abstract property of Kind, Subkind, Phase, Role, Collective, Quantity, and Relator is undefined, meaning that the classes can be abstract or not, depending on the situation.

If we consider that complete generalization sets do not make the superclass abstract, the abstract property should be set as FALSE instead of undefined. At least this is the only example I am thinking about now in which these types of classes would be abstract.

pedropaulofb avatar Feb 05 '22 13:02 pedropaulofb