I cry like the man in the classic anti-littering PSA whenever I read about implementations of the OGC's sensor "web" specification because environmental observation and real web architecture fit like a hand and a glove. What is an ASOS station or a data buoy if not a very dedicated and precise non-human blogger? Instead of routinely cranking out blurbs about Google Earth imagery updates, ArcGIS service patches, or RESTful architecture, it cranks out regular sets of scalar values: air or water temperature, dew point or salinity, wind speed or wave height.
ObsKML, too, recognizes the fitness of syndication for sensor observations, but KML doesn't really handle this kind of payload very well. Neither does RSS 2.0. Atom does have a general and robust content model that can deal with sensor observations as well as it does imagery or HTML: the observations go in an entry's content element, and all other entry elements serve as metadata.
... <entry> <id>urn:uuid:a261b59f-3692-4a00-a3bb-320a7448e0d8</id> <title>ASOS 89000 Obs</title> <updated>2009-03-14T16:00Z</updated> <georss:where> <gml:Point><gml:pos>-90.0 0.0</gml:pos></gml:Point> </georss:where> <!-- Human-readable summary --> <summary>Temp:-35.0, WindSpeed:5.0/10.0, WindDir:15.0, ...</summary> <content type="text"> <!-- ASOS data here --> 0187725020200111250051+40690-074170FM-15+0009KEWR... </content> </entry>
OpenSearch gives you a way to specify how a client slices a logical feed into bite-sized chunks. Goodbye, GetRecords(), GetCapabilites(), and GetObservations(). Hello, observations.