Species Ontology

The Species Example Ontology (SEO) SpeciesOntology models a small excerpt of the taxonomy initated by Carl Linnaeus. Classes, Set of Particulars and relators are represented as rounded boxes with titles highlited in red, green and purple. OPs are represented as octagons or round boxes, where their titles are highlited in blue. IIs are defined by, e.g., 
  (>NPS-Carl Linnaeus, ◊iof, ^Homo_Sapiens)
  (>ANM-Knut, ◊iof, ^Polar_Bear)
  (>ANM-Meng_Meng , ◊iof, ^Giant_Panda)
The latter two are both located in the >LOC-Berlin_Zoo. The first fact is modeled by
(>ANM-Meng_Meng , ◊Location, >LOC-Berlin_Zoo).
The second fact is modeled with the relator
(>ANM-Knut, >>Location_Knut, >LOC-Berlin_Zoo).
In contrast to [CaAl2011, p.21, Fig. 12] where taxons are connected via an extra OP ◊isSubordinateTo, our taxons are connected via ◊CategoryOf as object property chain

• ^Species ◊CategoryOf ^Genus ◊CategoryOf ^Family ◊CategoryOf ^Order ◊CategoryOf ^Tx-Class ◊CategoryOf ^Phylum ◊CategoryOf ^Kingdom.

At the same time they are all defined with ($taxon$, ◊subClassOf, ^Taxon).  With, e.g., ◊Genus = hOPN(Genus), all concrete species are ordered along the object property chain of taxons with, e.g.,  

• ^Polar_Bear ◊Genus ^Bear ◊Family ^Bears ◊Order ^Carnivores ◊Tx-Class ^Mammals ◊Phylum ^Chordates ◊Kingdom ^Animals.

The Transparent Data Property (TDP) .^warm-blooded defined in ^BiologyOrganism instantiates, e.g., into ^Bear with (^Bear,.warm-blooded,T). Thus, all IIs of bears are warm-blooded. The example for .ColourNameFur shows that all polar bears are modeled to have white fur colour, while the fur of all ^Giant_Panda is additionally black.

^Class and ◊ObjectProperty are subclasses of ^Resource. Thus, the Class Data Properties (CDPs)  .^^Instances and .^^Individuals can be instantiated into any knowledge subjects of the Schema Layer SL. E.g., (^Species,.^Instances,6) expresses that the class ^Species has 6 instances including itself, and (^Polar_Bear, .^Individuals, 31000) documents that the world wide population of polar bears is 31000. In general, a specification like (^Class, ◊subClassOf, ^Resource)  can be entailed with its inverse OP, namely (^Resource, ◊hasSubclass, ^Class).

An alternative to directly instantiating Particulars Data Properties (PDPs) is to use Partitioning Classes (PCs) . E.g., the root of the PC for the Transparent Data Property (TDP) dvp = .^Gender and the class c = ^Species is ^Species_by_Gender, and the Data Property Definition (DPD) asserted to the root is (^Species_by_Gender, .^Gender, ^String). For each v ∈ VS(.Gender) = {male, female} a subclass (^Species_by_Gender-v, ◊subClassOf, ^Species_by_Gender) is created. Then, with (>NPW-Carl_Linnaeus, ◊iof, ^Species_by_Gender-male), the knowledge subject >NPW-Carl_Linnaeus inherits the feature (.Gender,male). There is no reason why ^Species_by_Gender could not also be regarded as subclass of ^Species. But here, it is modeled as (^Species,◊Partition,^Species_by_Gender) in order to express that ^Species_by_Gender is a concept which one doesn´t want to be a regular subclass in a domain ontology. Nevertheless, instantiation is executed in the same way as if it were a regular subclass. PCs can be cascaded into hierarchies of PCs, e.g.,

• (^Body_of_Water_nt_ft, ◊subClassOf,^Body_of_Water_nt)
• (^Body_of_Water_nt_ft, ◊subClassOf,^Body_of_Water_ft),

where VS(.nt) = {natural,artificial} and VS(.ft)={floating,standing}. Then, e.g., with (^River, ◊subClassOf,^Body_of_Water_nt_ft), every particular of a ^River automatically inherits the features (ft,floating) and (nt,natural). As a consequence, for every II one triple is saved, and in general, if the cascade of PCs contains n DPs, then n–1 triples can be saved for every II.

PCs can also be used to model social roles, e.g., ^Employee_by_Academic_Degree, with

• (^BachelorEmployee, ◊subClassOf, ^Employee_by_Academic_Degree)
• (^PhDEmployee, ◊subClassOf, ^Employee_by_Academic_Degree)
• (^Employee_by_Academic_Degree, ◊is_Partition_Of,^Employee)

For instantiating a PC, instead of using ◊subClassOf, the OP ◊is_Partition_Of is used to express that the PC is not a ◊subClassOf of base classes ^Species and ^Employee.

In [CaAl2011] , pp , a fixed separation of entities into four Order Types (OT) either is discussed

• Particulars
• 1^st order type (1stOT)
• 2^nd order type (2ndOT)
• 3^rd order type (3rdOT)

From [CaAl2011], p.24, Fig. 13 follows:

• OoKE(MyMobile) =  OoKE(IPhone5) = OoKE(MobilePhone) =  0 and
• OoKE(MobilePhoneModel)  =  1.

In contrast, here we have

• OoKE(MyMobile) = 0;  
• OoKE(IPhone5)  =  OoKE(MobilePhone)  =  1.

After merging the pair (MobilePhone, MobilePhoneModel) into MobilePhone’, we have OoKE(MobilePhone’) =  1. I.e., the PT MobilePhoneModel has disappeared. On the other side, we have

• OoKE(>ANM-Meng_Meng) = 0;
• OoKE(^Giant_Panda) = 1, since (>ANM-Meng_Meng, ◊iof, ^Giant_Panda);
• OoKE(^Panda) = 2;
• OoKE(^AnimalSpecies) = 3;
• OoKE(^BiologyOrganism) = 4;
• OoKE(^Class) = 5;
• OoKE(^Resource) = 6.

Since there is no reason to limit the ◊subClassOf chain, it also makes no sense to restrict MLM to a fixed number of orders of KEs. Thus, in our MLM approach we distinguish as the two layers of abstraction only the Schema Layer (SL) which contains classes, meta classes, and OP definitions, and the Particulars Layer (PL) which contains only particulars.

Labeled Property Graphs (LPG): LPGs allow to annotate any kind of properties to OPs. Examples are the relators >>TaxonAuthor_Bear and >>Location_Knut. This has an analogy to the use of n:m relationship tables in relational databases. Each records in a n:m relationship table corresponds to an relator. When to use relators or when to use n-ary relationships is discussed in [HuBe2021], p. 111-112: In cases where there are exactly two participants being related by an object property, one can choose between the representation as direct relationship or as n-ary relationship. Typical examples of when direct relationships should not be used include when the participants in a relationship are not privileged. This is, e.g., the case with the object properties ◊Husband and ◊Wife in a marriage.

In our approach, we use OPs in analogy to classes, e.g.,

• (◊Location, ◊subObjectPropertyOf, ◊ObjectProperty).

Each edge between KEs are instances of the defining OP, e.g.,

• (>ANM-Meng_Meng, ◊Location, >LOC-Berlin_Zoo)

as feature (◊iof, ◊Location). The examples of the relators >>TaxonAuthor_Bear and >>Location_Knut demonstrate that OPs can instantiate DPs in the same way as classes do. To correct the example from [W3C-Punning], it is suggested to model as follows:

• (^Company, ◊PersonCompany, ^Company)
• (^PersonCompany, ◊subClassOf, ^Association)

Thus, there is no more need for punning. As already demonstrated before, the name of the OP can be automatically derived from the name of the class:

• ^PersonCompany → ◊hasPersonCompany = ◊PersonCompany
• ◊isPersonCompanyOf = ◊PersonCompany^-1.