From OpenOrg
Revision as of 14:07, 12 July 2011 by AlexDutton (talk | contribs) (added example)
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