Difference between revisions of "Metering"

From OpenOrg
Jump to: navigation, search
m (fix heading levels)
m (rewording)
Line 1: Line 1:
It is arguable that meter data isn't a good fit for RDF and SPARQL. With a hundred buildings with half-hourly readings you're looking at 2400 readings a day, and at ~5 triples per reading you're at 4 million triples per year.
+
It is arguable that meter data isn't a good fit for RDF and SPARQL. Given a conservatively estimated hundred meters with half-hourly readings you're looking at 4800 readings a day, and at ~5 triples per reading you're at 8 million triples per year.
  
 
Compounding the problem is the difficulty of retrieving data for date ranges, as this would require custom indexing in one's query processor.
 
Compounding the problem is the difficulty of retrieving data for date ranges, as this would require custom indexing in one's query processor.
  
 
== Overview ==
 
== Overview ==
 +
 +
We define a meter:Meter, which is a physical metering device. In most cases we don't care or know about them.
 +
 +
We also have a meter:MeterPoint, which is the concept of
  
 
== API specification ==
 
== API specification ==

Revision as of 13:36, 12 July 2011

It is arguable that meter data isn't a good fit for RDF and SPARQL. Given a conservatively estimated hundred meters with half-hourly readings you're looking at 4800 readings a day, and at ~5 triples per reading you're at 8 million triples per year.

Compounding the problem is the difficulty of retrieving data for date ranges, as this would require custom indexing in one's query processor.

Overview

We define a meter:Meter, which is a physical metering device. In most cases we don't care or know about them.

We also have a meter:MeterPoint, which is the concept of

API specification