Difference between revisions of "Metering"

From OpenOrg
Jump to: navigation, search
m (rewording)
(added example)
Line 7: Line 7:
 
We define a meter:Meter, which is a physical metering device. In most cases we don't care or know about them.
 
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  
+
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 ==
 
== API specification ==

Revision as of 14:07, 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