The type of schema discussed thus far uses only absolute ords. In situations with many points, absolute ords could limit scalability.
One schema per point or device would not be an efficient way to proceed. In the same way that relative ords in graphics enable
efficient engineering with the
A base query feeds base components to the schema, which the query resolves against the schema one at a time. In this manner it is possible to select, for example, all BACnet points in a station and output their name, status and present value for export to the cloud. If an engineer adds an extra device to the BACnet network in the future, the base query can automatically include it in the data exposed by the station, if the query allows.
Alone, a relative schema can select data to export or, when combined with an Export Marker, it can send only recent history or publish only when a set tolerance value is exceeded. Further still, you can move points between schema based on their status. You might have one schema that sends verbose point data and another with simple latest values once you add an export marker.
This base query would return all the overridden points beneath the Drivers container:
slot:/Drivers|bql:select * from control:ControlPoint where status.overridden = 'true'This query returns all points with the Haystack marker tag, hvac:
slot:/|neql:n:point and hs:hvacThe base query’s Publish Interval causes the base query to be re-executed periodically and triggers a complete publish output (of every returned component)
at the interval selected.
Invoking the Generate action on a relative schema evaluates the base query again.