Theory — reuse first
The 3-pass rule
Before declaring a new class, run three passes:
- Direct reuse — is there a standard class that means exactly what you mean? Use it as-is.
- Subclass / specialise — is there a standard class that means a generalisation of what you mean? Subclass it.
- Alignment — your concept is genuinely different, but related to an external one? Declare a
skos:closeMatchorowl:equivalentClass.
Only if all three fail do you mint a brand-new IRI. The industry name for skipping these passes is ontology soup — every team makes their own :Sensor, none of them interoperate, the LOD cloud weeps.
Applied to NorthWind
| We need… | Pass | Decision |
|---|---|---|
| 'Sensor' | 1 (direct reuse) | sosa:Sensor |
| 'Observation' | 1 | sosa:Observation |
| 'Feature of interest' (the turbine being observed) | 1 | sosa:FeatureOfInterest |
| 'Gearbox' | 2 (subclass) | :Gearbox rdfs:subClassOf :Component, :Component rdfs:subClassOf sosa:FeatureOfInterest |
| 'Wind farm' | 2 (subclass) | :WindFarm rdfs:subClassOf sosa:FeatureOfInterest |
| 'Vibration sensor' | 2 | :VibrationSensor rdfs:subClassOf sosa:Sensor |
| Degrees Celsius | 1 | qudt-unit:DEG_C |
Notice what we did NOT do: we never minted :Sensor, :Observation, :Unit. Every one of those would have cost us future interoperability for zero gain.