# Ontological Representation of Smart City Data: From Devices to Cities
## 4 Ontology Design Patterns Proposal for Smart City Ontologies
### Event ODP  
The model for this pattern has been reengineered from two vocabularies. The first model is the schema.org vocabulary, and it is taken into account because the _km4c_ ontology reuses this well-known model in order to represent an event. The second model is the Cultural Agenda Vocabulary ([[http://vocab.linkeddata.es/datosabiertos/def/cultura-ocio/agenda](http://vocab.linkeddata.es/datosabiertos/def/cultura-ocio/agenda)]([http://vocab.linkeddata.es/datosabiertos/def/cultura-ocio/agenda](http://vocab.linkeddata.es/datosabiertos/def/cultura-ocio/agenda))), referenced by the AENOR norm UNE 178301:2015, which is devoted to represent events in a city.  
In Table 9, the proposed pattern for the _Event_ domain is shown. The concepts _TemporalEntity_, _Interval_, and _Instant_ have been represented in order to model the time requirements. These concepts have been taken from the OWL-Time ontology, which, according to Table 4, is the most reused ontology for time representation in smart city ontologies. The _hasBeginning_ and _hasEnd_ OWL-Time properties may be used in order to represent the starting/ending date/hour of the _Event_. In addition, the concept _Interval_ has been extended by means of the class _NonConvexInterval_, which allows us to represent periodic intervals with gaps between them (e.g., \"every Wednesday\"), as is explained in [50].  
\begin{table}
\begin{tabular}{|l|l|} \hline
**Name** & City Object \\ \hline \multicolumn{2}{|c|}{**Description**} \\ \hline This pattern provides a model for an object that belongs to a city. \\ \hline
**Requirements** \\ \hline
**OBJ-1:** & A city object can be defined by a geometry. \\
**OBJ-2:** & A city object can be located in a given point. \\
**OBJ-3:** & A city can have city objects. \\
**OBJ-4:** & Each city object can have a location. \\
**OBJ-5:** & Some specific types of city objects can be: automated external defibrillator, urban furniture (bench, basket, street lights, etc.), cameras, or monuments. \\
**OBJ-6:** & A spatial thing can be a city object. \\ \hline \multicolumn{2}{|c|}{**Graphical representation**} \\ \hline \multicolumn{2}{|c|}{**Use Case**} \\ \hline A garbage container can be located at a given point in a street. By means of a sensor installed inside of the container, it could be possible to detect whether it is full. It could be used to redirect the waste truck route in order to optimize waste management. In addition, it could be used to send a notification to citizens in order to announce the proximity of the waste truck. \\ \hline
**Note** & The OBJ-5 requirement may be modeled by means of the _CityObject_ subclasses. For example, a sensor may be represented as a subclass of _Device_. \\ \hline \end{tabular}
\end{table}
Table 8: City Object ODP.  
With the aim to avoid a particular commitment, the concept _Agent_ has been defined. An _Agent_ can be any individual, organization, or group that organizes an _Event_. The _Agent_ could be represented by means of other ontologies, for example: FOAF, schema.org, etc. Finally, the property _accessibilityType_ has been used to link the _Event_ to an _Accessibility_ concept, which represents a concept from a controlled vocabulary where the accessibility types could be previously defined.  
It should be mentioned that in ISO/IEC 30182:2017, there is an _Event_ concept described as an occurrence that has happened or might happen. Such a concept of _Event_ could be considered as a generalization of the _Event_ presented in the present ODP, which is more specific.