Results

PRPR — Discussion & Conclusion

Discussion

Compared to the modeling of Carvalho and Almeida in [CaAl2016], Figure 14, we consider our approach to be more expressive in that it allows to merge the base class MobilePhone and the powertype class MobilePhoneModel while preserving the intended semantics. With regularity attributes alone, MobilePhoneModel cannot be subsumed under MobilePhone, because then each particular phone would also have a launchDate. Also, we do not need to add and maintain a feature such as potency for every data property. The way in which potency is used by Frank [Fran2022] has the consequence that non-trivial continuous updates of the potency values are required when extending the class hierarchies. Our methodology dictates which instantiation rule is to apply by using the prefixes in the DP names. Also, in our approach, as in deep instantiation, universals can have both instance and type character simultaneously. This is comparable to clabjects as presented by Atkinson and Kühne [AtKu2001]. In the paper by Neumayr et al. ([NeSc2008], page 9, figure 3) the base classes Book and Car are modeled as subclasses of ProductCategory. We would merge the ProductCategory with the class Product and avoid a forced division into classification levels. Also for the same reason, compared to the modeling in [NeSc2008], page 11, figure 4 we see no need to explicitly model ProductModel to be classifiedAs ProductCategory.

Meta Data

If one wants to model not only the application domain but also the model of the domain model, then this is done by Meta Data Properties (MDPs). As a convention, we agree that MDPs are defined in the O4Top schema (figure o4toptl2). This is similar to the Dublin Core Metadata Initiative. In the adopted example AnnotationAssertion(a:createdBy a:Dog "Seth MacFarlane") from OWL2 the createdBy attribute can be considere a typical MDP and we would place its definition in »^Resource with (»^Resource, ..createdBy, :String). Thus, any ontology element in the instantiation chain down from »^Resource can take an MDP assertion for ..createdBy.

Attribute Propagation

Dahchour et al. in [DaPi2002], page 8, give examples for the three different types T1, T2 and T3 of attribute propagation. T1 propagation corresponds to our method Value Assignment Propagation (VAP) by Transparent Data Properties (TDP). However, what is missing in [DaPi2002] as an instantiation method is the ability to specify that values for attributes in classes may not propagate into particulars as provided by Universals Data Properties (UDP). This prevents the authors from defining resultant properties (as defined in [GuFi2019], page 2) such as .^qtySold or .^maxSpeed_km-p-h, which would lead to erroneous value propagation if additional metaclasses were not introduced. We map their T0 propagation to MDPs in our methodology. We have also shown that metaclass constructs such as  instance-type or instance-instance-type are not needed to capture the semantics of generic relationship types, contrary to what is shown on page 14 of [DaPi2002]. This also means that by using TDPs the various approaches shown in figure 12 on page 14 for materialization with meta classes are not required.

Multi-Level Features

Following the list of multi-level features F1, ..., F8 presented by Fonseca et al. in [FoAl2021], we discuss how our approach meets their requirements:
  • F1: Figure mobjects shows with the »subClassOf, »subModelOf hierarchy how we can represent entities of multiple classification levels.
  • F2: The number of classification levels is not limited.
  • F3: The guiding principles for organizing models are given by the criteria for selecting the appropriate type of data property as described in section.
  • F4: Our most generic modeling entity is »^Resource as shown in the O4Top schema in figure o4toptl2. It allows universals such as classes and object properties to inherit data properties and to propagate pairs of DPs and values down a hierarchy.
  • F5: The rules governing the instantiation of related types are given by the DP restrictions in section. In figure mobjects we have shown, how the powertype ^Car_Model can be subsumed under the base type ^Car.
  • F6: The feature of supporting the representation of properties (data properties and relationships) of types as well as the assignment of values to their instances was discussed in the section Examples.
  • F7: Figure dptypes explains the relationship between DPs of entities in different classification levels. There, the »subModelOf classification level is aligned under the »subClassOf classification level where ◊subModelOf ⊆ ◊subClassOf due to »subModelOf ≤◊ »subClassOf.
  • F8: The representation of domain relations between entities of different classification levels is supported without durability, mutability or potency.

Type Cascading Supposition (TCS)

If ^Car_Model is the PowerType (PT) of ^Car then we can write PT(^Car) = ^Car_Model. The question then arises, is there also a ^Car_Model powertype, e.g. ^Car_Model_Model = PT(^Car_Model) = PT(PT(^Car))? We think not, because what attributes could PT(^Car_Model) have? In the example shown in figure mobjects, we used the Object Property (OP) »subModelOf to subsume car models under the base class car. In analogy the same would work for (Bird, Bird_Species) with »subSpeciesOf, for (Person, Person_Role) with »subRoleOf, for (Product, Product_Category) with »subCategoryOf and so on. As a modeling guideline, we can deduce that the name used to specify the powertype can be used to find the name for the subsumption OP. In general, we create the OP Name »subSpecOf for Class_Spec. Then with (»subSpecOf, »supOpOf, »subClassOf) and (»subClassOf, »supOpOf, »is) it holds in general ◊subSpecOf ⊆ ◊subClassOf ⊆ ◊is. The example in figure mobjects also shows that, compared to other instantiation methods such as deep or dual deep instantiation ([CaAl2011], [GuAl2015]), we do not need to annotate with a feature such as potency.

Conclusion

We have discussed how to extend Conceptual Modeling (CM) to appropriately provide the features needed for Meta-Level Modeling (MLM). Many other MLM approaches require features such as potency, durability and mutability. This places a heavy burden on the modelers, since any change in an inheritance hierarchy may require the renumbering of potencies. We circumvent this problem by introducing simple naming conventions for the four required data property types. We have provided criteria for selecting the appropriate data property type. As shown in the Examples section, it is possible to implement powertypes and their subsumption as well as the attribution of binary and n-ary relation types. However, MLM makes higher demands on the modeler, because he has to understand and master additional instantiation mechanisms. But the advantages are greater expressiveness, lower memory requirements, less complex models and as a side effect, layer mistakes can be reduced or even eliminated. So, as a general guideline for modelers, we suggest, to prefer MLM, since the backdoor to return to CM is always open.

Extension: deriver.app

Combined mirror of PRPR Discussion and Conclusion. Back to Multi-Layer Modeling (MLM); Deriver documentation.

Sources: PRPR Discussion, PRPR Conclusion.