Provenance
In a system where many sources of information are available, it is useful to be able to merge data. This has the advantage of creating a single result, but comes at the cost of relying on data which may not be completely accurate. It is useful therefore to be able to track back, to see where data came from.
Consider two sensors, a bluetooth location sensor and ubisense location sensor. It makes sense to merge readings from these two sensors to create a single location reading. Should this reading be inaccurate, it would also make sense to find which sensors were responsible. In this example, we will create an ontology for a ‘virtual’ location sensor and a derived location observation. (For more on sensors and observations, see sensing) In doing so, we will explain how provenance information is inserted, so that the original observations can be tracked down.
First, the sensor. The description of this sensor is very simple, just describing how often a location is derived, which device it i running on and the expected rate of change of the reading.
###locationRateOfChange
:locationRateOfChange time:seconds "10"^^xsd:int .
###locationSensor
:locationSensor rdf:type sensor:Sensor ;
sensor:runningOn sensingDevice:sensingDevice ;
sensor:frequency :locationRateOfChange ;
sensor:rateOfChange :locationRateOfChange .
###locationSensorFrequency
:locationSensorFrequency time:seconds "1"^^xsd:int .
Next is the observation. This is also quite simple. Here we simply have the result, a location and links to the observations(note: not the sensors) from which the result was derived. In this case, Bob is sighted in bobsCubicle(see Location). This result was derived using two readings: bluetootObservation105 and ubisenseObservation1102.
### http://ontonym.org/08/sensor/locationObservation.owl#locationObservation
:locationObservation provenance:derivedFrom
bluetoothObservation:bluetoothObservation105 ,
ubisenseObservation:ubisenseObservation1102 ;
sensor:observed map:bobsCubicle .
No Comments Yet