From OpenOrg
Revision as of 14:45, 12 July 2011 by AlexDutton (talk | contribs)
Jump to: navigation, search

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.


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


  • 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)