恒温器所在的房间，为何未必代表所有遥测对象的位置

OGC于2016年公布的SensorThings API Part 1: Sensing 1.0，把Thing定义为能够被识别并纳入通信网络的物理世界或信息世界对象。定义同时容纳实体与虚拟对象，因此Thing首先是模型中可识别的对象身份，不能只从英文日常含义把它缩成一台有固定摆放地点的实物设备。[1]

与Thing相连的观察资料又有分组身份。第7.3节将Datastream解释为按同一个Sensor和同一个ObservedProperty聚在一起的Observations。这里所保留的是观察资料共同涉及哪一个传感来源、哪一种被观察属性。Datastream因而不是Thing所在地点的另一种名字：按何种观察属性分组，与一个对象最后位于哪里，回答的内容并不相同。[1]

第8.2.2节为Location给出了明确参照：Thing最后已知的位置。这个定义所定位的是Thing，而后续文字还会问，观察所关心的对象位于什么地方。只将两个名称都翻译成一个没有归属的“位置”，就会先删去位置分别属于哪一项对象这一层信息，读者也无法知道它与后面的观测目标怎样相连。[1]

室内恒温器例展示两者可以相合的情形。联网恒温器位于一栋建筑或其中一个房间，温度读数的FeatureOfInterest也可以是该建筑或房间。这个房间一方面是恒温器所在之处，另一方面又是室温读数所描述的对象。两个角色可以指向相同空间，不等于设备、房间和温度数值因此成为同一个东西。[1]

FeatureOfInterest这个名称在第8.2.8节另有解释：观察结果给某个现象赋值，这个现象是某个对象的属性，而该对象就是这次观察的FeatureOfInterest。接回恒温器例，房间作为对象、房间的温度属性和这次得到的温度结果，各有位置。来源使用房间作为共同参照，并没有将温度结果本身定义成设备的位置。[1]

遥感情形则明确保留不相合的可能。标准说，Thing的最终关注位置不总是Thing本身所在地；FeatureOfInterest可以是正在被感知的地理区域或体积。此时，设备位置内容与观察目标内容不同。前面的房间例说明二者有时相同，这里的区域或体积例说明不能把那种相同关系推广为所有观察记录的定义。[1]

HistoricalLocations又把记录对象限定回Thing自身。第7.3节说，当Thing的位置变化时，这类实体提供Thing位置的历史。它保存的是这个对象曾位于哪里的资料，不会仅凭名字带有Historical，就自动成为每个Observation目标的完整移动轨迹。一个关注设备位置变化的历史，与一次遥感观察关注哪片区域，仍须沿各自所指的对象理解。[1]

本文仅解读上述历史标准的静态对象关系，不发送消息、布置传感器、执行API或推断实际农业作业已经完成。[1]

资料来源：
[1] [OGC SensorThings API Part 1: Sensing 1.0 (15-078r6)](https://docs.ogc.org/is/15-078r6/15-078r6.html)