Definitions

ONMA — definitions, O4Top, instantiation (concatenated mirror)

Before answering any of the questions raised in the Introduction section, we need to introduce some naming conventions and graphical notations. These are mainly based on the author‘s article [Bens2014].

Name Sets:

Let N be the set of strings containing all possible sequences of arbitrary length, including the empty sequence, that can be generated from the characters of a given character set. As our key naming convention, the name of an ontological entity always uses the index of the designating set as its prefix: N_x = {xn | n ∈ N}. To unambiguously denote the names of ontological concepts we introduce the following name sets: N_^ is the set of class names, N_. is the set of data property names, N_◊ is the set of object property Names, N_> is the set of particular names, N_» is the set of relator names, N_° is the set of process names, N_~ is the set of function names, and the union of the sets is N^* = ∪ { N_x | x ∈ { ^, ., ◊, >, », °, ~ }}. In short, the symbols are motivated to evoke associations with hierarchies, properties, processes, things in flux, and references / pointers. This means that the name sets defined in this way form the vocabulary of a meta-language for compact and expressive notations. For example, the RDFS definition of a class ^Car based on our naming conventions is: ^Car rdf:type rdfs:Class.

Knowledge Graphs:

We represent an ontology by a Knowledge Graph (KG). A Knowledge Graph is defined as KG ⊆ N x N x N. As in RDF each element is a triple of the form (s, p, o) which we call Atomic Knowledge Expression (AKE). First, we define the inverse axiom which we think is very important for a General Ontology Theory because it concerns every triple of a KG. For every property p there exists a property q = p^-1 such that the following axiom holds:

{{definition:InvAx:InvAx = Inverse Axiom:(s, p, o) ∈ KG ⇔ (o, q, s) ∈ KG.}}

Filters:

Let M be a set and ≤ be a non-strict, acyclic, transitive ordering relation. The pair (M, ≤) is a non-strictly ordered set. A principal filter and a principal ideal are special subsets of a partially ordered set (see Ganter and Wille, [GaWi2024]). We use principal filters to model hierarchies of super-elements symbolized by the ∵ icon, and to model hierarchies of sub-elements with principal ideals, symbolized by the ∴ icon:

{{definition:PF:principal filter:∵τa = {x ∈ M| a ≤_τ x} is the principal filter of τa.}}

{{definition:PI:principal ideal:∴τa = {z ∈ M| z ≤_τ a} is the principal ideal of τa.}}

Hierarchies:

As a foundation for ontological engineering, we provide the minimal ontology blueprint called O4Top as shown in Figure o4toptl2 as an implementable artifact in the sense of [HeMa2004]. We do not consider O4Top as a top-level ontology, but as a blueprint according to which ontologies should be constructed. For the visualization of knowledge graphs called OntoGraphs we use the symbols and naming conventions which have been introduced by Bense in [Bens2014]. The different colors and shapes for the various ontology elements enable modelers to understand the models more quickly and help him to identify and correct errors, and to reduce developing costs. Compared to other top-level ontologies, the O4Top ontology blueprint contains as a minimal set of ontological elements ^Class, ◊ObjectProperty, .DataProperty, and »^Resource. Having »^Resource as the most generic modeling entity was motivated by Allemang et al. who state in [AlHe2020], page 37: “a resource can be anything that someone might want to talk about”. Classes correspond to formal concepts in Formal Concept Analysis as we will discuss in detail below. Object Properties (OP) represent binary relationship types between classes. A particular is the instantiation (see section Instantiation) of a class and bound to the class with the binary relationship type »pof (particularOf). A relator is the instantiation of a binary relationship type or, in the case of n-ary relations, the binding of one particular to n other particulars.

For completeness, we mention the »^UResource and the additional types of data properties ..MetadataProperty, .ΔTransparentDataProperty, and .^UniversalsDataProperty for streamling conceptual modeling and Meta-Level Modeling (MLM), which are explained in the author‘s article [Bens2023a] and are not relevant to the discussion in this paper.

Fig. O4TopTL: O4Top Ontology Blueprint

For an ontology O, with C we denote its set of classes, with A its set of Data Properties (DP), with R its set of Object Properties (OP), with E (Extension) its set of class particulars, and with EE = E X E its set of object property instances. The OPs ◊subClassOf, ◊subDpOf and ◊subOpOf are acyclic, transitive relationship types and form hierarchies using the order relations ≤_◊, ≤_∧, and, ≤_.:

x ≤_∧ y ⇔ ∃x, y ∈ C: (x, »subClassOf, y) ∈ KG ∨ (y, »hasSubClass, x) ∈ KG
x ≤_◊ y ⇔ ∃x, y ∈ R: (x, »subOpOf, y) ∈ KG ∨ (y, »hasOp, x) ∈ KG
x ≤_. y ⇔ ∃x, y ∈ A: (x, »subDpOf, y) ∈ KG ∨ (y, »hasDp, x) ∈ KG

The pair C∴ = (C, ≤_∧) is the class hierarchy structure where for each c ∈ C the subclass hierarchy of c is defined as ∴c. Its top element is sup(∴c) = c and sup(C) = ^Class. The set of super classes of c is defined as ∵c.
The pair R∴ = (R, ≤_◊) is the hierarchy structure of object properties where for each r ∈ R the sub OP hierarchy of r is defined as ∴r. Its top element is sup(∴r) = r and sup(R) = ◊ObjectProperty. The set of super OPs of r is defined as ∵r.
For data properties the pair A∴ = (A, ≤.) is the hierarchy structure of data properties where for each a ∈ A the sub DP hierarchy of a is defined as ∴a. Its top element is sup(∴a) = a and sup(A) = .DataProperty. The set of super DPs of a is defined as ∵a. E.g., .GivenName ≤_. .PersonName ≤_. .Name

Instantiation

The smallest instantiation step is to create or update a (s, p, o) triple. There either a data property or an object property is involved. The first requires a Data Property Definition (DPD) as template, the second an Object Property Definition (OPD). Instantiation patterns specify what form the resulting triple must have. Now we define patterns for Data Property Instantiation (DPI) and Object Property Instantiation (OPI) where a ∈ A is a Data Property, adt ∈ ADT is an Atomic Data Type, u is a universal either from the set C of classes or from the set R of object properties, ^C and ^D are classes, and v is a value from the value set of attribute a:

Data Property Instantiation (DPI):

Then each DPI must map to one of the following patterns where the symbol ⊨ relates the property definition template to its allowed property instantiations. The first rule expresses that a DPD can be used to instantiate particulars or universals. The second rule expresses that binary and n-ary relations between objects can also have data properties. We refer to the next section where we will define the function pof() to return the set of particulars of a class .

(u, A, adt) ⊧ (x, A, v) where (x, »pof, u) or x ∈ ∴u
(◊OP, A, adt) ⊧ (»OPI, A, v) for relators with (»OPI, »opi, ◊OP)

Object Property Instantiation (OPI):

An Object Property Definition (OPD) has the short form (^C, ◊OP, ^D). The classes ^C and ^D may be identical. Then the possible Object Property Instances (OPI) for Particular-Particular Relationships (PPR) and for Class-Particular Relationships (CPR) are:

OPI: Let >P1 ∈ pof(^C) and >P2 ∈ pof(^D), then (>P1, »OP, >P2) is an object property instance of (^C, ◊OP, ^D).
PPR: (>P, »isOPOf, ^C), or also its inverse (^C, »hasOP, >P) both mean that for an OPD (^Person, ◊isDesignerOf, ^Car) the particular >P on the particulars layer is connected with ^C on the schema layer, for example, (>Ferdi_Porsche, »isDesignerOf, ^VW_Beetle) and (^VW_Beetle, »hasDesigner, >Ferdi_Porsche).

Object Property Instantiation Rules (OPIR):

Be ◊OPOf = ◊OP^-1, and >P1 ∈ pof(^C), and >P, >P2 ∈ pof(^D). For PPRs and for CPRs and their inverses we get as OP instantiation rules:

PPR: (^C,◊OP,^D) ⊧ (>P1,»OP,>P2); (^D,◊OPOf,^C) ⊧ (>P2,»OPOf,>P1)
CPR: (^C,◊OP,^D) ⊧ (^C,»OP,>P); (^D,◊OPOf,^C) ⊧ (>P,»OPOf,^C)

Extension: deriver.app

Same ONMA sources as in Theory (separate subpages). Axioms under Preliminaries. Deriver documentation.

Sources (single page, canonical blocks concatenated in this order): ONMA — Definitions, ONMA — O4Top, ONMA — Instantiation.