Ontologies: Towards Semantic Networks

Operators already have enormous volumes of data and events, but they lack a unified semantic understanding of relationships, dependencies and impact. What we are proposing goes one step further than most current observability systems:

• not merely modelling topology,

• but modelling operational meaning and human impact.

The gap in current monitoring systems

Most monitoring systems today are fundamentally device-centric and answer questions like:

• Is the interface down?

• Is latency high?

• did a threshold breach?

• did an alarm fire?

Even sophisticated systems often stop at:

• root-cause correlation,

• service impact estimation,

• SLA violation prediction.

They generally do not model: 

• what does a failure in some part of the system mean for the customer, 

• what kind of customer is being affected

• how severe is the likely human/business impact?

We are proposing to connect hard ontology entities (sites, routers, switches, DNS servers, optical links, metrics, scores etc) with soft ontology entities (customers, personas, triggers, frustration levels, business criticality etc).

Where hard ontologies are:

• structural,

• measurable

• operational

And soft ontologies are:

• behavioural,

• experiential

• contextual

Why this matters: a fiber cut affecting:

• a domestic streaming customer,

• a hospital,

• an emergency service,

• a high-frequency trading firm,

May look identical technically to a:

Interface down.

However, semantically, they are radically different events.

Ontology introduces meaning propagation rather than merely alarm propagation. This is an important distinction.

What ontologies add

Ontologies allow systems to represent:

• Dependency, for example:

Port → Slot → Chassis → Service → Customer

• Semantics:

A DNS outage may not affect customers immediately due to host caching

• Contextual reasoning:

Example: packet loss on a backup service versus packet loss on emergency voice service would score differently even if their respective raw metrics are identical.

• Human impact inference, for example:

Service degraded → Trigger fires →Customer frustration increases

This is a fundamentally different operational model from traditional NMS systems.

What this could yield

Customer-aware observability: Instead of:

Port 16 Down

The system could infer:

• 40 domestic users mildly impacted

• 2 enterprise customers critically impacted

Priority-aware automation: Closed-loop remediation could prioritize based on:

• Persona triggers

• Frustration

• Pain points 

• Business criticality

• Predicted churn

Better incident narratives: Instead of raw alarms, LLMs could generate:

A fault on ATH chassis 1 slot 7 is degrading DNS resolution

for residential gaming customers in the northern region.

Intent-aware networking: With ontologies, we are approaching: intent semantic; not just network state semantics. For example:

maintain acceptable gaming experience.

Rather than:

keep latency below 40ms.

This is a major conceptual shift. A particularly powerful aspect is that we are treating:

customer frustration.

as something derivable from:

• infrastructure state,

• service topology,

• persona semantics.

Most systems today do NOT formally model this. At best they  nfer sentiment afterward from support calls or social media. Whereas, we are proposing: 

predictive semantic impact.

This naturally extends toward:

• semantic service assurance

• human-aware network operations

Summary

Traditional monitoring systems know when devices fail. Ontological systems can know what those failures mean — operationally, commercially and ultimately humanly, as:

• topology explains structure,

• ontology explains meaning,

• personas explain consequences.

What makes your approach particularly interesting is that it is:

• mathematically compositional,

• operationally grounded,

• and semantically extensible.

Instead of merely attaching labels to alarms, ontologies enable a propagating semantic model of network consequence. This is much closer to what future autonomous OSS systems will likely require than today's threshold-and-dashboard monitoring alone.