# Semantic Traffic Sensor Data:
## 4 Data Annotation and Publishing
### Identification of Relevant Concepts and Properties
The same approach has been used for the attribute \"nearest_node\", adding the link [[http://linkedgeodata.org/triplify/node](http://linkedgeodata.org/triplify/node)]([http://linkedgeodata.org/triplify/node](http://linkedgeodata.org/triplify/node)) to the identifier of the node, which is another element of OSM. Two new properties have been defined to connect a sensor to its way and its nearest node, called _trafair:isLocatedInOSMWay_ and _trafair:hasNearestOSMNode_, respectively (see Figure 5). Moreover, the name of the city where the sensor is located has been added. The city has been identified by exploiting the class _dbo:Place_ of the DBpedia Ontology [69], and the property _dbo:Location_ to link the instance of the class _dbo:Place_ to the traffic sensor. Concerning the \"sensor_traffic_observation\" entity type in Figure 3, the Km4 City ontology has been exploited. Each instance of this entity type represents an observation made by one sensor. An instance of the class _km4c:Observation_ identifies the observation. Since the primary key of the corresponding \"sensor_traffic_observation\" table is composed of three attributes (identifier of the sensor, timestamp indicating the beginning of the observation, and type of vehicles observed), the URI of each observation has been created as the concatenation of the values of these attributes. The property _km4c:measuredBySensor_ has been used to connect the observation to the sensor, while the properties _km4c:vehicleFlow_ and _km4c:averageSpeed_ have been exploited to indicate the number of vehicles and their average speed, respectively. The property _rdfs:label_ has been used to represent the type of vehicles, which is enough for representing the names of the types of vehicles; as an alternative, an existing ontology of vehicles, like the Vehicle Ontology or the Vehicle Sales Ontology, could have been extended (it should be noticed that the Vehicle Ontology available at [[https://enterpriseintegrationlab.github.io/icity/Vehicle/doc/index-en.html](https://enterpriseintegrationlab.github.io/icity/Vehicle/doc/index-en.html)]([https://enterpriseintegrationlab.github.io/icity/Vehicle/doc/index-en.html](https://enterpriseintegrationlab.github.io/icity/Vehicle/doc/index-en.html)) does not currently define subclasses of the concept \"Vehicle\" and that the Vehicle Sales Ontology available at [[http://www.heppnetz.de/ontologies/vso/ns](http://www.heppnetz.de/ontologies/vso/ns)]([http://www.heppnetz.de/ontologies/vso/ns](http://www.heppnetz.de/ontologies/vso/ns)) does not cover all the types of vehicles managed in TRAFAIR; however, new concepts can be added as needed). Figure 5: Definition of the “isLocatedInOSMWay” and the “hasNearestOSMNode” properties. The last two attributes hold the start and the end of the time interval of the observations. Different kinds of sensors send measurements with different time intervals, while defining how to aggregate the original data when sharing this information is up to the public administration that owns the data. The second attribute is a new attribute calculated over the first attribute adding the time interval the observation refers to. These attributes have been mapped using the _prov.startedAtTime_ and _prov.endedAtTime_ properties of the PROV-O ontology [70]. Figure 6 shows the triples generated for a sample traffic observation. In Appendix A, the data model, based on the identification of the relevant concepts and properties explained in this section, is shown.