---
title: 'FCD-OntoArch: Layered Ontological Architecture'
url: https://www.emergentmind.com/topics/fcd-ontoarch
type: topic
---

# FCD-OntoArch: Layered Ontological Architecture

FCD-OntoArch is a layered ontological architecture for sciences in which ontological modules are arranged so that higher levels provide semantic anchors and lower levels provide increasingly specialized content. Across the cited literature, the acronym is expanded as “Foundational, Core, Domain and instance Ontological Architecture for sciences” and as “Foundational, Core, and Domain Ontological Architecture for Sciences”; in both formulations, the architecture comprises a Foundational level, a Core level, a Domain level split into Top-Domain and Low-Domain sub-levels, and an Instance level. It is presented as enforcing clear separation of concerns, reusability, and semantic enrichment across layers, with exactly one foundational ontology at the Foundational level and progressively more specific ontologies below it [2107.09129], [2104.09232].

## 1. Architectural stratification

The architecture is described in some sources as “four-layered” because the Domain level is treated as a single layer that is “split down in two sub-levels,” and in others as explicitly “five-tiered” because those sub-levels are counted separately. The reported tiers are Foundational Ontological Level (FO), Core Ontological Level (CO), Top-Domain Ontological Level (TDO), Low-Domain Ontological Level (LDO), and Instance Ontological Level (IO) [2107.09129], [2107.10083].

| Level | Role | Reported examples |
|---|---|---|
| FO | Most general, domain-neutral primitives | ThingFO |
| CO | Domain-independent core ontologies | ProcessCO, SituationCO, GoalCO, PEventCO, ProjectCO |
| TDO | Abstract upper-domain concepts for specific scientific fields | TestTDO, FRsTDO, NFRsTDO, MEvaITDO |
| LDO | Specialized ontologies for narrower subdomains | MetricsLDO, IndicatorsLDO |
| IO | Individuals only | UnitIO; test runs; concrete TestResult individuals |

At FO, the architecture contains exactly one foundational ontology. At CO, it hosts domain-independent core ontologies that build directly on FO terms. At TDO, it encodes abstract, upper-domain concepts for specific scientific fields. At LDO, it contains specialized, finely grained ontologies for narrower subdomains. At IO, it is populated only by individuals of classes defined in FO or lower levels; in the TestTDO account this is phrased as “purely ‘ABox’ or instance data ontologies,” and no new taxonomic structure is introduced [2107.09129], [2104.09232].

A central architectural consequence is that ontologies at the same level can be related to each other, except at the foundational level, where only ThingFO is found. This yields a stratified but non-isolated organization: lateral integration is allowed above FO, while vertical dependence is constrained by explicit correspondence and enrichment conditions [2107.09129].

## 2. Layer constraints and meta-axioms

The architecture is governed by two guidelines and three rules in the ThingFO presentation, and by a corresponding set of meta-axioms in the TestTDO presentation. Guideline #1 states that every ontology must be situated within an explicit layered architecture and that a foundational ontology must occupy the FO tier. Guideline #2 states that FO must host exactly one foundational ontology to satisfy completeness, conciseness and delegation of concerns. Rule #1 requires that a CO, TDO or LDO ontology guarantee correspondence of its elements to those at the immediately higher level, enabling semantic enrichment. Rule #2 allows ontologies at the same tier, except FO, to interrelate provided their combined semantics do not violate the next higher level. Rule #3 states that IO contains only individual instances of particular Thing classes defined above [2107.09129].

The TestTDO formulation recasts these constraints in terms of a level function $\ell$ over ontologies. Its Axiom F1, “monotonic referencing,” states that if there is a non-taxonomic relation or class/property-level reference from an element in ontology $O_i$ to an element in ontology $O_j$, then $\ell(O_i) \ge \ell(O_j)$. Axiom F2 forbids the converse case: if $\ell(O_i) < \ell(O_j)$, then no such reference is permitted. Axiom F3 states that if $\ell(O_i)=\ell(O_j)$, then the ontologies may relate freely. This formalization makes the architectural discipline explicit: lower or equally placed ontologies may refer to higher or same-level ontologies, but higher-level ontologies may not be enriched by or refer to more specific ones [2104.09232].

Further global constraints are reported as Axiom M1, foundational exclusivity; Axiom M2, no downward enrichment; and Axiom M3, domain sub-level ordering. M3 specifies that TDO and LDO are ordered by specificity, so that TDO ontologies may relate to each other and to CO and FO, while LDO ontologies may relate to each other and to all of TDO, CO, and FO; TDO may not refer to LDO. A recurrent misconception is therefore that FCD-OntoArch is a permissive network of peer ontologies. The published axioms instead define a strict layering regime with controlled reuse and prohibited upward references [2104.09232].

## 3. Foundational substrate: ThingFO v1.3

ThingFO v1.3 is the sole occupant of FO and supplies the domain-neutral primitives for the entire architecture. It introduces three disjoint, exhaustive concepts: **Thing**, **Thing Category**, and **Assertion**. A Thing is defined as “a class or type of perceivable or conceivable object in a particular world,” with synonyms including Particular Thing, Object, Entity, Instance, and Individual. A Thing Category is a mental abstraction or class that predicates on Things but has no direct instances in the world; it produces subcategories but does not instantiate individuals. An Assertion is a positive, explicit statement about Things or Thing Categories, based on observations, beliefs or intentions. Assertion has subclasses for assertions on particulars and universals, and further thematic specializations such as Action-related, Relation-related, and Time-related assertions [2107.09129].

The reported class vocabulary includes Thing, Property, Power, ThingCategory, Assertion, AssertionOnParticulars, AssertionOnUniversals, and the typed assertion subclasses ActionRelatedAssertion, AllotmentRelatedAssertion, BehaviorRelatedAssertion, ConstraintRelatedAssertion, IntentionRelatedAssertion, QualityRelatedAssertion, QuantityRelatedAssertion, RelationRelatedAssertion, SituationRelatedAssertion, StructureRelatedAssertion, SubstanceRelatedAssertion, and TimeRelatedAssertion. Datatype properties include `name` and `description` for Thing, `name` and `structuralDescription` for Property, `name` and `behavioralDescription` for Power, `descriptiveStatement` for ThingCategory, and `name`, `positiveStatement`, and `specification` for Assertion. Object properties include `actsUpon`, `belongsTo`, `dealsWithParticulars`, `dealsWithUniversals`, `defines`, `enables`, `generalizes`, `interactsWithOther`, `isSeenAsOther`, and `relatesWith` [2107.09129].

The foundational logical core is expressed through axioms linking Property, Power, and Thing. Three key first-order axioms are stated:

$$
\forall t\in Thing\ \forall p\in Property\ \forall w\in Power\ [\ partOf(p,t)\ \wedge\ enables(p,w)\ \Rightarrow\ partOf(w,t)\ ]
$$

$$
\forall t\in Thing\ \forall w\in Power\ \forall p\in Property\ [\ partOf(w,t)\ \wedge\ actsUpon(w,p)\ \Rightarrow\ partOf(p,t)\ ]
$$

$$
\forall t\in Thing\ \forall w\in Power\ [\ partOf(w,t)\ \Rightarrow\ \neg interactsWithOther(w,t)\ ]
$$

These axioms constrain how powers and properties may be attributed within the same Thing and prohibit a power from interacting with its own Thing via `interactsWithOther` [2107.09129].

The UML conceptualization is reported as showing three top-level, disjoint and exhaustive classes—Thing, ThingCategory, Assertion—while also showing the taxonomic relations `ThingCategory ⊑ Thing` and `Assertion ⊑ Thing`. This suggests that the presentation combines a foundational partitioning claim with a UML taxonomic rendering, a point that requires careful reading rather than immediate equation of the two notational perspectives [2107.09129].

## 4. Semantic enrichment and stereotypes

Semantic enrichment is the mechanism by which lower-level ontologies acquire the semantics of higher-level ones. In the architecture, this is implemented primarily through stereotypes of the form `« ns:TermName »` or `<< SourceOnto::Term >>`. The TestTDO account formalizes the mechanism with two axioms. Axiom S1 states that if `Stereotype(c, «ns:C′»)` holds, then $c \sqsubseteq ns:C′$. Axiom S2 states that if `Stereotype(p, «ns:P′»)` holds, then $p \sqsubseteq ns:P′$. In OWL terms, class stereotypes generate `SubClassOf` axioms and property stereotypes generate `SubPropertyOf` axioms [2104.09232].

The published examples are explicit. `TestParticularSituation « SCO:ParticularSituation »` yields `TestParticularSituation ⊑ SCO:ParticularSituation`, and `PerformTesting « ProcCO:WorkProcess »` yields `PerformTesting ⊑ ProcCO:WorkProcess`. The TestTDO paper reports “≈ 40 enriched terms” obtained in this way. The SituationCO presentation characterizes the semantic effect of the stereotype mechanism by stating that the lower-level term inherits the complete set of properties and non-taxonomic relationships of the source term, unless further constrained [2104.09232], [2107.10083].

This enrichment is directional. Lower-level ontologies can be semantically enriched by ontologies’ terms and relationships from higher levels, but the inverse is prohibited. The ProcessCO presentation summarizes this as “foundational imports only flow upward,” while the TestTDO meta-axioms prohibit both forbidden upward references and downward enrichment. A direct implication is that semantic reuse is explicit and auditable: every enrichment is tied to an identifiable stereotype tag and corresponding subsumption axiom [2108.02816], [2104.09232].

## 5. Realization in core and domain ontologies

The architecture is instantiated by a set of core and domain ontologies that refine the foundational substrate while preserving its constraints. ProcessCO v1.3 resides at CO and captures the “generic anatomy of work entities—Processes, Activities, Tasks—and their traditional workflow companions (Products, Resources, Roles, Conditions).” Its classes include WorkProcess, Activity, Task, WorkEntity, ProductEntity, WorkProduct, NaturalProduct, Service, WorkResource, Agent, HumanAgent, AutomatedAgent, Method, Tool, Strategy, Time, Money, Role, Condition, Allocation, AllocationModel, ProcessPerspective, ProcessModel, and several categories. Its non-taxonomic relations include `consumes`, `produces`, `involves`, `isPlayedBy`, `isAssignedTo`, `dealsWith`, `uses`, `isApplicable`, `isRequiredBy`, `pertainsToCategory`, `setsPrecondition`, `setsPostcondition`, `relates`, and `dealsWithWorkEntity`, all declared as sub-properties of corresponding ThingFO relations. ProcessCO v1.3 also adds six first-order axioms ensuring that any consumption, production or role-involvement specified at a high level is consistently grounded in the process decomposition tree [2108.02816].

SituationCO v1.2 is another CO ontology and is domain-independent. It reuses and specializes terms mainly from ThingFO, ProcessCO, ProjectCO, GoalCO, and PEventCO. Its principal classes include GenericSituation, ParticularSituation, Situation, SituationModel, Organization, Project, Goal, GenericGoal, SpecificGoal, ParticularEvent, TargetEntity, ContextEntity, EnvironmentEntity, ArtificialEnvironment, NaturalEnvironment, SpaceEntity, TimeEntity, ContextCategory, and EntityCategory. Its object properties include `worksAt`, `establishes`, `conceives`, `arrangesWorkBy`, `operationalizes`, `specifies`, `impliesUniversals`, `impliesParticulars`, `abstracts`, `dealsWithTarget`, `dealsWithEnvironment`, `isSurroundedBy`, `influences`, `pertainsTo`, `pertainsToCategory`, and `relates`. Its axioms A1–A3 constrain target/context separation, require surrounding context when both target and context are present in a ParticularSituation, and require the existence of a ParticularSituation when a ContextEntity influences a TargetEntity [2107.10083].

At TDO, TestTDO v1.3 is placed at the top-domain level and extends SituationCO and ProcessCO concepts. The reported procedure is: declare TestTDO at $\ell=2a$; for each software-testing concept that reuses a core concept, add the appropriate stereotype; freely relate TestTDO classes among themselves while respecting monotonic referencing; and never introduce relations from a core class into TestTDO in the opposite direction. The same architectural procedure is said to govern other TDO ontologies such as NFRsTDO and FRsTDO [2104.09232].

NFRsTDO v1.2 provides a further top-domain example. It is devoted mainly to quality requirements and quality/cost views and is placed at TDO. Its terms and relationships are mainly extended or reused from ThingFO, SituationCO, ProcessCO, and FRsTDO. Reported classes and constraints include `NonFunctionalRequirement`, `Attribute`, `Characteristic`, `StatementItem`, `EvaluableEntity`, `EvaluableEntityCategory`, `NFRView`, and `NFRsModel`; reported relations include `belongsTo`, `refersToParticulars`, `refersToUniversals`, `relatesWith`, `combines`, `satisfies`, and `isMappedTo`. In v1.2, `FunctionalRequirement` is reused from FRsTDO and the property `satisfies` links non-functional requirements to functional requirements [2302.01096].

Low-domain ontologies such as MetricsLDO and IndicatorsLDO refine top-domain constructs, and IO ontologies populate the classes of TDO and LDO with actual individuals. The TestTDO account explicitly notes that low-domain ontologies may reuse TestTDO via stereotypes `«TestTDO:…»` as well as any CO or FO classes, after which instance data ontologies populate the classes of TDO and LDO with actual individuals [2104.09232].

## 6. Reported implications, use cases, and interpretive points

The architecture is reported to bring five principal consequences. **Modularity & Reuse** follows from shared FO primitives that prevent duplication and ease integration across scientific domains. **Semantic Interoperability** follows because lower-level ontologies align via clear mappings to FO, facilitating cross-domain queries and reasoning. **Scalability** is attributed to the ability of new TDO and LDO ontologies to slot under FO and CO without reworking existing models. **Rigorous Consistency** follows from FO axioms imposing global constraints such as part-of and disjointness that propagate through layers. **Traceability** follows because all classes ultimately derive from Thing, ThingCategory, or Assertion, making provenance and conceptual lineage explicit [2107.09129].

The reported use cases illustrate how these consequences are intended to operate. One is a bio-informatics knowledge graph in which “Molecule” is a ThingCategory inheriting FO structural constraints and its “ReactsWith” relation is a subproperty of `interactsWithOther`. Another is the development of scientific workflows in ProcessCO linked to experimental Assertions in an LDO, with FO ensuring consistency of `actsUpon` versus `interactsWithOther`. A third is an instance-level repository of concrete measurements, such as TemperatureReadings, typed by QuantityRelatedAssertions from FO [2107.09129].

Two recurrent interpretive points deserve emphasis. First, the “four-layered” versus “five-tier” formulations are not contradictory in the sources; they reflect whether the Domain level is counted as one level or as two sub-levels, TDO and LDO. Second, the architecture should not be read as allowing arbitrary cross-level coupling: foundational exclusivity, monotonic referencing, forbidden upward references, and no downward enrichment jointly define a strict, axiom-governed layering [2104.09232]. A plausible implication is that FCD-OntoArch is best understood not merely as a catalog of ontologies but as a constrained design pattern for ontology engineering in which reuse, specialization, and instance population are all explicitly regulated.

Source: https://www.emergentmind.com/topics/fcd-ontoarch