MLM Related Work

In the Semantic Web, a metaclass is defined as a class whose instances are classes. Metaclasses are often mentioned in the literature [AtKu2003,BeHu2021,BrAl2016b,CaAl2011,GuAl2015,PiZi1994,Fran2014,AlMu2019]. They refer to conceptual modeling with RDF/RDFS, OWL, UML, OMG or in OOA/OOD etc. The layers are usually structured according to the following scheme: a knowledge entity is an instance of order 0, or a First-Order-Type/Class (1stOT). A second-Order-Type/Class (2ndOT) instantiates entities of 1stOT, a 3rdOT instantiates entities of 2ndOT etc. In section 5, we show that this kind of ordering is not relevant and superfluous within our approach, thus avoiding the potency for layer mistakes/errors.

Pan and Horrocks [PaHo2001] criticize: "RDF schema, as a schema layer Semantic Web Language, has a non-standard metamodeling architecture, lacks clear semantics, and is suitable for "layer errors": "Although class and subClassOf can be defined as resources in RDF, RDF provides neither a standard mechanism for declaring classes and (global) properties nor mechanisms for defining the relationships between properties and between classes. Some elements also have a dual role in the RDFS specification. This makes it difficult for modelers to understand and use them. They also find it confusing that rdfs:Class is a subclass of rdfs:Resource, while rdfs:Resource itself is also an instance of rdfs:Class".

Pan and Horrocks also find it confusing that "although rdfs:Class is the rdf:type of Animal, both Animal and rdfs:Class are rdfs:SubClassOf rdfs:Resource, where rdfs:Class is a modeling primitive and Animal is a custom ontology class".  In [NeSc2009] it is argued that the metamodeling approaches of materialization [PiZi1994], performance types and potency-based deep instantiation [AtKu2003] were developed for different purposes and complement each other. From our point of view, the most important summary of the authors‘ comparison is the following: The materialization pattern is not suitable for adding additional levels to certain sub-hierarchies and does not provide special support for relationships. Also they argue that the powertype approach does not completely avoid fragmentation and redundancy. And for power-based deep instantiation, they argue that it makes it more difficult to model non-uniform sub-hierarchies and that the approach cannot avoid several unconnected model elements at different classification levels with respect to fragmentation.

In our approach, ^Resource is the most abstract meta-modeling unit. All other classes and OPs are direct or indirect subclasses of ^Resource.

In[BrAl2016b] the term Regularity Attribute RA was coined for those properties which are discussed in class data properties (CDP) .

In the field of MLM, various authors ([BrAl2016b], [CaAl2011], [GuAl2015], [NeSc2009], [Odel1994], [PiZi1994]) discuss modeling pairs of classes where a class is associated with a corresponding type class. Given a class c like Car, Phone or Bear, then the pt = PT(c) holds the type and kind information about c, e.g.

• MobilePhoneModel = PT(MobilePhone)
• Bear_species = PT(Bear)

In [PiZi1994] a PT is used with a materialization pattern (MP) for

• car_model = PT(car).

"A type is a property that is rigid and carries an IC. Types play the most important organizational role in a taxonomy. Assuming that each type has a distinct set of ICs, we have that, according to Lowe´s principle, a taxonomy of types is always a tree. When a type specializes another type, it adds further ICs to those carried by the subsuming type."

E.g., at the merological level the ICs are extensional. Two entities are the same if and only if they have the same parts. But he also writes: „In practice, ICs for classes corresponding to natural language words are difficult or impossible to express.“ The problems addressed can be avoided by our approach, i.e., in the case of hypernyms/hyponyms by carefully differentiating between (^X, ◊subClassOf, ^Y) and Word Sense Definitions (WSD) like

• WSD(x) = (>BLS-x, ◊Def, CBT(y))

Wiki definition of Identität (Logik):

• In logical systems, identity is introduced via indistinguishability: the identity principle states that an object A is identical to an object B if and only if no difference can be found between A and B. The method by which identity is recognized is comparison. The identity principle is often attributed to Gottfried Wilhelm Leibniz and is therefore also called the Leibniz law (Leibniz' law).
• The philosophical formulation of a principle of the "Identity of the indistinguishable" goes far back and can already be found in the considerations of the Stoics, the modern view of identity goes back to considerations by Leibniz. The historical discussion of the intuitive properties of the indistinguishable is mostly found under its Latin catchphrase as principium identitatis indiscernibilium.

Leibnitz: „Eadem sunt quae sibi ubique substitui possunt, salva veritate“ („Dieselben sind, die sich überall ersetzen können, bei Wahrung von Wahrheit“)

The authors of [CaAl2011] discuss the PT pair MobilePhoneModel = PT(MobilePhone): Instances of the PT MobilePhoneModel like iPhone5 have properties like launchDate or instancesScreenSize. iPhone is a subclass of the class MobilePhone which is partitioned by MobilePhoneModel (see partitioning classes. With traditional modeling approaches it is not possible to mix the properties MobilePhoneModel and MobilePhone into one class since, e.g., it makes no sense to have a property launchDate in the particular MyMobile or imei in the subclass IPhone5 of MobilePhone. Also, it is not possible to instantiate the standard ScreenSize of the IPhone5 into MyMobile. As a solution to the latter, they use regularity attributes (RAs) instancesScreenSize with the naming convention: RA(ScreenSize) = instancesScreenSize;  In general, the RA naming pattern is: RA(Attribute) = instancesAttribute. Then, two facets of IPhone5 can be modeled, the first as ◊iof (is instance of) MobilePhoneModel and the second as a subclass with ◊subClassOf MobilePhone. With this mechanism it becomes also possible to model MyMobile as ◊iof IPhone5 because it can instantiate ScreenSize through the facet of IPhone5 being a◊subClassOf MobilePhone.  Compared to [AlMu2019] in the approach presented here it is strictly differentiated between Instances Of Classes (IoC) and particulars. Compared to [CaAl2011] , the approach here is simpler insofar as it does not require separate entities MobilePhone and MobilePhoneModel, at the same time preserving multi-level semantics.

Another approach to avoid separate entities Car and Car_Model which is called Multi-Level Domain Modeling is described in [NeSc2009]. Properties are annotated with meta attributes which define rules for inheritance and instantiation. E.g., for the base class Car, the data property maxSpeed is annotated with :model to refer to a Car_Model, while the DP Milage is annotated with :physical_entity to refer to a particular of Car. This allows to merge the properties of Car and Car_Model into only one class Car, while keeping the semantics of the properties clear.  In a comparable approach [Fran2014], level numbers are assigned to properties.  For Car, the property Milage would be defined with level=0 (potency = 0), which corresponds to the :physical_entity annotation of [NeSc2009], while maxSpeed would be annotated with level=1, which corresponds to the :model annotation. Compared to the approach in this work, annotating properties with multiple levels or with different levels for different contexts is not possible. In this approach, it will be shown that the specification of the DPs as :physical_entity is not necessary, because DPs of the powertype Car_Model like maxSpeed can be specified as Class Data Property CDP, e.g.,  .^^maxSpeed. This restricts the instantiation to :model classes and keeps CDPs from being instantiated into particulars.

The authors of [BeHu2021] discuss a dual-facet instantiation mechanism based on type/class hierarchies. Their example models the particular :Knut with

• (:Knut,a,:Polar_Bear)
• (:Polar_Bear, a, :Species)
• (:Polar_Bear, :population, 31000)
• (:Polar_Bear, a, rdfs:Class)
• (:Species, a, rdfs:Class).

Since the taxon :PolarBear is as instance of class :Species (instance facet), and since also :Polar_Bear is a rdfs:Class, it exposes dual-facet behaviour. With :Knut as an instance (class facet) it does instantiate properties like :birthDate and :birthPlace of :Species, but it does not instantiate :conservation_status and :population of :Polar_Bear. Thus, it was possible to merge (:Polar_Bear, :Polar_Bear_Species) into one class :Polar_Bear. Also, they show that inferencing can be used to implement the desired inheritance behaviour with rules implemented as a simple SPARQL query. Depending on the application context, entities can be assigned to different modeling levels, and properties can be annotated with different inheritance behaviour, and different inheritance rules can be implemented. In contrast to other related work, the authors of [BeHu2021] argue that their guidelines can be fully implemented using the W3C standards RDF/RDFS, and SPARQL, allowing to implement inheritance behaviour using standardized inferencing mechanisms.

In [AlMu2019] the problems are identified that: „using the powertype pattern […] creates a number of difficulties. First of all a modeler needs to handle explicitly two notions of instantiation. The pattern is based on the duplication of the instances of the powertype”. In their ML2 Multi-Level Modeling Language, expressions of instantiation between classes are represented by a colon, e.g., Lion: AnimalSpecies . In our approach in Figure ML2, no additional notation is needed and we simply model (^Lion, ◊is, ^Animal) and subsume ^Animal under ^Species.