FCD-OntoArch: Layered Ontological Architecture
- FCD-OntoArch is a layered ontological architecture consisting of Foundational, Core, Domain (Top and Low), and Instance levels that enforce clear separation of concerns and semantic consistency.
- It employs strict layer constraints and meta-axioms to ensure semantic enrichment flows only upward, prohibiting downward or cross-level misreferences.
- Real-world implementations like ProcessCO and SituationCO illustrate its practical utility in promoting reusability, traceability, and interoperability across scientific disciplines.
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 (Olsina, 2021, Tebes et al., 2021).
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) (Olsina, 2021, Olsina et al., 2021).
| 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 (Olsina, 2021, Tebes et al., 2021).
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 (Olsina, 2021).
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 (Olsina, 2021).
The TestTDO formulation recasts these constraints in terms of a level function 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 to an element in ontology , then . Axiom F2 forbids the converse case: if , then no such reference is permitted. Axiom F3 states that if , 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 (Tebes et al., 2021).
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 (Tebes et al., 2021).
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 (Olsina, 2021).
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 (Olsina, 2021).
The foundational logical core is expressed through axioms linking Property, Power, and Thing. Three key first-order axioms are stated:
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 (Olsina, 2021).
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 (Olsina, 2021).
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 . Axiom S2 states that if Stereotype(p, «ns:P′») holds, then 0. In OWL terms, class stereotypes generate SubClassOf axioms and property stereotypes generate SubPropertyOf axioms (Tebes et al., 2021).
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 (Tebes et al., 2021, Olsina et al., 2021).
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 (Becker et al., 2021, Tebes et al., 2021).
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 (Becker et al., 2021).
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 (Olsina et al., 2021).
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 1; 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 (Tebes et al., 2021).
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 (Olsina et al., 2023).
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 (Tebes et al., 2021).
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 (Olsina, 2021).
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 (Olsina, 2021).
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 (Tebes et al., 2021). 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.