Urban Computing examples for "Requirements" section of the NEFORS paper
- numerosity
- heterogenity
- Representative
- Semantic
- default (termine corretto)
- time dependency
- Diverse Uncertainty and Inconsistency
Representative Heterogeneity
Urban Computing-related data can come from different and independent data sources, which can be developed with traditional technologies and modeling methods (e.g., relational DBMS) or expressed with "semantic" formats and languages (e.g., RDF/S, OWL, WSML). For example, geographic data are usually expressed in some kind of geographic standard; events details are published on the Web under the form of RSS feeds; traffic data are stored in databases; etc. The integration and reuse of those data therefore need a process of conversion/translation for the data to become useful together.
Semantic Heterogeneity
Urban Computing use cases have different requirements with regards to data processing and reasoning: some data need precise and consistent inference (e.g., knowing if two roads are connected (si può svoltare o è vietato, è un ponte), esiste un percorso con certe caratteristiche (checking if private cars are allowed to enter a specific urban area), etc.), while other data need approximate reasoning or imperfect estimations (e.g., calculating the probability of a traffic jam given the current traffic conditions e la storia passata). Therefore, the requirement is for different kinds of techniques and reasoners to deal with those kinds of data; moreover, another requirement is for a system which dynamically selects and runs a specific reasoner on the basis of the available data and the desired processing tasks.
Default Heterogeneity
(probably the current example as in the paper is ok for CWA vs OWA but not for UNA)
Diverse Uncertainty and Inconsistency
dati che arrivano con diversi ritardi temporali e diversi sampling rate un pool di sensori che danno informazioni contrastanti:
- telecamera che inquadra un incrocio in cui non ci sono macchine (informazioni aggiornate ogni secondo ma con ritardo di 30 secondi)
- spiere che ti segnalano il passaggio di veicoli (quanti ne sono passate negli ultimi 5 minuti ma con un ritardo di 10 minuti)
data difficult to interpretate alone traffico 0
- strada bloccata
- strada vuota
- macchina parcheggiata sul sensore
- sensore rotto
tipo di sensore
- sensore che misura solo i passaggi
- sensore che misura anche il tipo di veicolo
=> il numero di veicoli contati può essere diverso perché quello che conta solo i passaggi non sa distinguere una macchina (veicolo corto) che passa piano da un camion (ceicolo lungo) che passa veloce
Data Scheduling for Scalability
The advent of Pervasive Computing and Web 2.0 technologies led to a constantly growing amount of data about urban environments, like information coming from multiple sensors (traffic detectors, public transportation, pollution monitors, etc.) as well as from citizens' observation (black points, commercial activities' ratings, events organization, etc.). The result, however, is that the amount of data available to be used and integrated is not manageable by state-of-the-art technologies and tools and a severe focus on scalability issues must be taken into account. For example, intelligent methods for data sampling or selection should be adopted before employing traditional reasoning techniques, e.g. to select traffic data to employ in predictions;