Theory — modular Turtle
Why split?
A monolithic northwind.ttl would couple the asset team (who manage the physical hierarchy) and the sensor team (who manage observation types) into one shared file. Every asset edit becomes a sensor PR. Every sensor edit risks breaking asset queries.
The modular pattern:
asset-core.ttl— pure structure (turbines, components). Owned by the reliability engineering team.sensors.ttl— sensor classes, observable properties, alarm-classifier inference. Owned by the data team.events.ttl(next module to ship) — alarms, work orders, owned by ops.
Each module declares owl:imports for what it depends on. Each module ships on its own release cadence — asset-core rarely changes; sensors evolve with the sensor catalogue.
The EL-safe alarm inference
We could define a :HighTempObservation like MedaCore did — equivalentClass with a numeric threshold. But OWL 2 EL doesn't allow owl:hasValue over xsd:decimal directly, and arithmetic comparisons (> 80) are NOT OWL at all. Threshold checks belong in SHACL or the SCADA layer. The ontology's job is to classify what kind of observation it is (gearbox temperature, blade vibration), not to evaluate inequalities.
This is one of the most common rookie mistakes: trying to do math in OWL. OWL classifies; SHACL/SQL/SCADA compute.