Difference between revisions of "Metering"

From OpenOrg
Jump to: navigation, search
(added example)
Line 20: Line 20:
  
 
== API specification ==
 
== API specification ==
 +
 +
 +
 +
== Usecases ==
 +
 +
* Entire data
 +
* Data for "now" for all meters (compared with average for this time of day / day of week )
 +
* Show data for today/week/year
 +
* Various levels of granularity (day, week, month, year)

Revision as of 14:45, 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 something that kicks out readings. A meter:MeterPoint is then linked to a metering endpoint definition. Something like:

 <#meterPoint> a meter:MeterPoint ;
   meter:endpointSpecification <#endpointSpecification> .
 <#endpointSpecification> a meter:EndpointSpecification ;
   meter:endpoint <#endpoint> ;
   meter:endpointIdentifier "my-meter-point" ;
   dcterms:temporal [ # something ] .
 <#endpoint> a meter:Endpoint .

API specification

Usecases

  • Entire data
  • Data for "now" for all meters (compared with average for this time of day / day of week )
  • Show data for today/week/year
  • Various levels of granularity (day, week, month, year)