Two STA servers can parse each other perfectly and still carry four different definitions of CO₂. That is what a controlled vocabulary and UCUM would fix.

[bharkema]

Of everything in our topic 2 work, this is the finding I would most like to see the programme act on. It came out of reading another participant's server, not out of writing to one.

We pointed a generic reader at a testbed STA server we knew nothing about. No documentation, no schema, no conversation with its operators. A couple of days later we had replicated its entity graph: 46 ObservedProperties, 460 Datastreams, in a domain (pump telemetry, seismics, air quality) with no overlap at all with our own waste containers. That is a real win for the standard, and it is cheaper than any vendor API integration we have ever done.

Then we tried to make the data mean something, and stopped.

That one server holds four distinct co2_levels ObservedProperties, each with its own @iot.id and its own definition URI, drawn variously from QUDT, Wikipedia, DBpedia and CF conventions. Same story for gauge_pressure, battery_level and temperature_indoor. Some unitOfMeasurement values are null, and some are placeholders, literally "...".

To be clear: none of this violates STA, and none of it is a criticism of that server. It is well-formed, its data is valid, and it does nothing the specification asks it not to. That is exactly the problem. A consumer still cannot answer "give me all CO₂ readings in this area", not across servers and not even inside that one server, without someone curating a mapping by hand. Avoiding that work is why we adopt standards.

This is a profile problem, not a spec bug

ObservedProperty.definition is a free URI and unitOfMeasurement is effectively free text. That openness is deliberate and defensible: no standard can enumerate every phenomenon in every domain. But it does mean OGC 18-088 delivers syntactic interoperability and then stops, by design. The semantic layer is what a national profile is well placed to pin down, and pinning it down needs no change to the specification at all.

What we would propose for a Dutch STA profile

• A mandated controlled vocabulary per domain for ObservedProperty.definition, with the URI required to resolve to a term in that vocabulary rather than to any page that happens to describe the concept.
• UCUM required for unitOfMeasurement.symbol. Null only where the specification explicitly allows it, meaning a stream with no unit such as OM_TruthObservation, never as a placeholder.
• A conformance checker, so "profile-compliant" becomes something a server passes or fails rather than an intention.

Best value for effort of anything in our report, because it is the layer the base standard deliberately leaves open and the layer where a national ecosystem gains most from simply agreeing.

Two questions for the group

1. Would a profile along those lines be usable in your own deployments?
2. Which vocabularies should we start from rather than invent? Aquo looks like the obvious candidate for the water domain and NEN 3610 for the geo side, but I would rather hear what people are already committed to.

Would love to hear all the opinions and input on this.

[mathisvfr]

Strong support from the connector side. This was our most frustrating finding despite not being a bug.

We pin every ObservedProperty.definition to a CF Standard Names URI and every unitOfMeasurement.symbol to a UCUM code. The full list we use:

Parameter	CF Standard Name	UCUM symbol
Temperature	air_temperature	Cel
Relative humidity	relative_humidity	%
CO₂	mole_fraction_of_carbon_dioxide_in_air	[ppm]
Air pressure	air_pressure	hPa
PM2.5	mass_concentration_of_pm2p5_ambient_aerosol_particles_in_air	ug/m3
Groundwater level	water_surface_height_above_reference_datum	m
Wind speed	wind_speed	km/h
Precipitation	precipitation_amount	mm
Solar radiation	surface_downwelling_shortwave_flux_in_air	W/m2

This cost us maybe two hours to set up and it has been zero maintenance since. That confirms the claim that this is high value for low effort.

On vocabularies to start from: CF Standard Names works well for atmosphere, climate, and hydrology parameters. For the water domain specifically, Aquo is indeed the obvious Dutch candidate since it is already the national standard there. For units, UCUM is unambiguous and machine-parseable, which is the whole point. We would not mix unit authorities.

On question 1 (would a profile be usable): yes, and we would adopt it immediately. We already follow these conventions voluntarily; a profile would just mean others converge on the same choices, which is the part we cannot do unilaterally.

On question 2 (which vocabularies): for our climate adaptation domain, CF Standard Names + UCUM covers everything we measure. For a broader Dutch profile spanning water management, the combination of Aquo (domain terms) + CF (physical quantities) + UCUM (units) seems like it would cover most use cases without inventing anything new. The conformance checker Bart proposed would be the piece that turns this from a recommendation into something enforceable.

[znetsixe]

The above list will break again as soon as you go into mass flow or other engineering units.
The only way to properly do it is to setup the standard as a conversion. Example code: https://git.wbd-rd.nl/RnD/generalFunctions/src/branch/main/src/convert
This uses anchor points so you arent redoing each conversion again as well. example speed is just a singular anchor and many translations of that anchor point.

Also Im not sure who should hold this standard but the sta server isnt meant to hold the truth of the unit. for sure it should be standardized how the unit is written down, with caps, without caps , with / or without etc... but STA shouldnt manage that.

My 2 cents is a standard approach chosing like an ISA standard for P&ID symbols as an example and they just agree to use those. If not according to the standard then you dont find it through lookups.

Second idea is to semantically search for units and then convert them to the right input each time but that costs alot of compute in between and again needs a standard.

My own conclusion is , we as waterboard should ensure following the name convention if any and all talk the same language forcing it from our backend not forcing it on the STA because als this costs alot of compute verifying it on STA side. which you typically wont want in order to obtain high throughput speed?

[mathisvfr]

Fair point, ended up doing it on our side. Added a small canonical table in the connector