Meeting: Chapter 4

# Meeting: Chapter 4 **Date: 09-09-2022** ## Agenda **Regarding your questions:** 1. I think it does - Javier is a better judge I would guess. The geographic component is of course in a way limited. What have been recent developments / you mot recent reference to a paper is 2019, but most are older. 2. A few generic remarks. There should be much more cross referencing between chapters. I have feeling there is also lots of double between chapters, because they have been composed individually before (this includes definitions, terms, descriptions). Partly it is because of the rigorous structure (which is ok). But you also have to check every location where you use the word ‘Recently’. Often that refers to situation when text / paper was originally developed. 3. No specific comments on graphics. 4. Suggest the three of use set up a meeting - preferable physical at ITC to discuss the ‘last mile’ * Feedback from Menno-Jan * 1. I think it does - Javier is a better judge I would guess. The geographic component is of course in a way limited **(ASK for clarifications, maybe include map examples of the problem we address).** What have been recent developments / you mot recent reference to a paper is 2019, but most are older **(Extend literature review to more recently works, look into sensors and geoinformation, how people use sensor in geographic domain, standards (ISO, OGC), new directions in geo-world: org is folowing the lead of the industry rather than define its own particular ways to implement datandads and procedure, iot in geo).** * Check example by Javier on Dutch sensor netwok * 2. A few generic remarks. There should be much more cross referencing between chapters **(check for flow betwen chapter, and add cross reference instead of repeating.)** * I have feeling there is also lots of double between chapters, because they have been composed individually before (this includes definitions, terms, descriptions). Partly it is because of the rigorous structure (which is ok). **check if repetion is because structure or content** * But you also have to check every location where you use the word ‘Recently’. Often that refers to situation when text / paper was originally developed. **Check and change** * 3. No specific comments on graphics. * 4. Suggest the three of use set up a meeting - preferable physical at ITC to discuss the ‘last mile’. ## Language Desing The langage provides a ways to define datastreams and detections patterns (somehithing very common in other CEP languages). The **datastream** definition let uses to define what data is relevant for a geografic evevent `e`. The **partern** definition let users define conditions to the attribute, spatial and temporal properties of `e`. ### Concrete Syntax Below, I describe the ambitioned concrete syntax for the language. To define a geographic event `e`, a user declares a datastream (data of interest) and a pattern (a set of contions over the attributive, spatial and temporal values of a data stream). #### Data representation (Datastreams) The general concrete syntax for datasteams is a follows: ```javascript= // General sintax datasteams <datastream> = { << observation_type >> : [ {<observation_name1>: <data_type>}, {<observation_name2>: <data_type>}, {<observation_namen>, <data_type>} ], << location >>: [ <feature1>, <feature2>, <featuren>] << time >> : [ <time_instance1>, <time_instance2>, <time_instancen>] } ``` ## Considerations - time in implementation: become borrower with ideas, and combine ideas and enrich - Two sructures: - Event declaration (declare a structure that is direclty implementable, direct mapping into what is currently possible (sensor-things, etc)) - Event processing (system implementation): implementation does not have to be a CEP engine, it can be a combination of other tools (sensor thing api, python scripts, other cep engines) - Can we try to specify a simple event so that it can be processed by a single service (funcition (sensor_type, rules)). Then composite events, become the use and orquestration of all simple events. This requires to declare also which service each > The location of an event `e` is the union of all *features* > The time of an event |e| is the union of all *time_instances* #### Detection Rules ```javascript= // attributive condition // unary rule <datastream>.<observation_type> <<operator>>> <condition_value> // n-ary rule <unary_rule> <<operator>> <unary_rule> datastream.<observation_type> <<comparison operator>> <condition_value> <<logical operator>> datastream.<observation_type> <<comparison operator>> <condition_value> // spatial condition // temporal condition ```  ## Use Case: Traffic Jam A user wants to detect the occurrence of traffic jams in a section of a road which is equiped with Piezoelectric sensors [1,2] at both ends of a road that "according to common or custom-made schemes... provides **volume, speed, direction, traffic gap and headway**[4] data."[3] "The cause of a traffic jam is a function of speed and density. As density increases, speed tends to decrease which causes more density. ![Piezoelectric sensor](https://www.windmill.co.uk/images/piezoelectric-traffic-counter.jpg "piezoelectric sensor") ![headway](https://www.researchgate.net/publication/309476899/figure/fig1/AS:547959508922368@1507655135464/Definition-of-gap-headway-and-tailway.png "Headway and traffic gap") So, we ask: - What defines a **traffic jam** on a road? - What *traffic phenomena* defines a traffic jam for the road? - number of vehicles on the length of the road lane (e.i. how many vehicle are within the lentgh of the road lane?) a.k.a. traffic density [5] - traffic volume/flow (vehicle/time-unit) *"The flow is equal to zero in two cases - either when there is no traffic (no cars present on the road) or when all vehicles are stuck in a traffic jam and cannot move forward."* - speed (km/h) > REASONING: > For a lane of the road monitored by two sensors, one at the beginning of the road lane $S_b$ and one at the end of the same road lane $S_a$, separtated by a lenght $L_{(ab)}$. The traffic density for such a road lane during a period of time $t$, and the counts of vehicle on both sensors $Count_{(S_a)}$ and $Count_{(S_b)}$ during that same period, can be computed as: > > $Density_{(t)} = \frac{(Count_{(S_a)} - Count_{(S_b)})}{L_{(ab)}}$ > > However, the "flow and density are directly linked to the **average travel speed**. These three are called the fundamental characteristics of a traffic flow, and the following formula links them: $flow = speed * density$" [5] Which means that for practical purposes (including the definiton of relevant observable phenomena about traffic), **the average speed on a point or section of a road is a good approximations for detecting a traffic jam on such a road, regardless of the road's capacity.** > **We will ignored the practial case for the sake of definig the primitives of the language** - What **observable properties** of traffic phenomena are measured by piezoelectric sensors on the road? - volume (vehicles/hour), - speed (Km/h), - direction (?) - traffic gap (m) - headway (m) - What contextual information is required to define a traffic jam on the road? - capacity of the road - What simple and composite events are need to define a traffic jam on the road? - a car entering the road lane for time $t$ - a car leaving the road lane for time $t$ - excesive traffic volume (a function of road capacity) - traffic jam ### Examples Using the synxtax above: ```javascript= // General sintax datasteams /* <datastream> = { << observation_type >> : [ {<observation_name1>: <value_type>}, {<observation_name2>: <value>}, {<observation_namen>, <value>} ], << location >>: [ <feature1>, <feature2>, <featuren>] << time >> : [ <time_instance1>, <time_instance2>, <time_instancen>] } */ // SIMPLE EVENTS: level 1 // DESIGN: declaring data types or values might not be important car_entering_road = { observation_type: [ {axel_activation: boolean } ], // Null -> default all locations location : Null, // consider location of sensor time : Null // default any time. // DESIGN: no declaration default to Null } // Detection rule: None // DESIGN: can detection rules be declared directly on data streams? car_entering_road.axel_activation != Null car_leaving_road = { observation_type: [ {axel_activation: boolean } ], location : Null, time : Null } // Detection rule: None r1 = car_entering_road.axel_activation != Null // COMPOSITE EVENTS: level 2 excesive_volume = { observation_type: [ { car_entering_road: object }, { car_leaving_road: object } ], // the extent of the road lane location: ['POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))'], time: ['10 min'] // time interval // DESIGN: temporal granularity for the computation of the event } // Detection rule // asuming a road_capacity = of 8 vehicles in a road lane 100 m long // that's equivalent to a speed of 15 Km/h if the flow = 20 vehicle/min // DESIGN: when the rule applies report the value?? r2 = ( sum(excesive_volume.car_leaving_road) - sum(excesive_volume.car_entering_road) ) > 8 // COMPOSITE EVENTS: level 3 // considering flow of 100 vehicles/ 10 min traffic_flow = { observation_type: [ {car_entering_road: object} ], location: ['POINT (30 10)'], time: ['10 min'] } // DESIGN: this is not valid javascript syntax to access the objects in an array r3 = traffic_flow.car_entering_road >= 100; // 100 vehicles passing the // first sensor every 10 mins // DESIGN: this looks too complicated and unnecessary to apply only a // time constraint traffic_jam = { observation_type: [ { excesive_volume: object }, {traffic_flow: object} ], location: Null,// not relevant [ 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))' ], time: [ '08:00:00', '17:00:00' ] // time interval // DESIGN: temporal granularity for the computation of the event } r4 = traffic_jam.excesive_volume & traffic_jam.traffic_flow /* * DESIGN: can r3 and r4 be declare in the same rule? * -> What to do with the two different time constraints * * Can some of the code be nested? * -> is it a good idea to allow nesting? Check the general sintaxy in the notes. * Can the code be shorten? * -> rember that in any programing languages, there are usually * sevel was to write the same program * */ ``` #### Other Questions related with event examples. How to define a gegraphic event for a traffic jam on a sensor network? Want to detect where temperature in a building is over 50 degrees? When is too much traffic going to the street? time: 1 hour Piezoelectric sensor= weight of vehicle, type of vehicle ( bicycle, truck, car) ### References [1. google scholar](https://scholar.google.nl/scholar?as_ylo=2021&q=traffic+Piezoelectric+Sensor&hl=en&as_sdt=0,5&as_vis=1) [2. type of traffic sensors](https://www.windmill.co.uk/vehicle-sensing.html) [3. commetial piezoelectric sensor](https://metrocount.com/wp-content/uploads/2021/08/MetroCount-RoadPodVP.pdf) [4. headway](https://www.researchgate.net/figure/Definition-of-gap-headway-and-tailway_fig1_309476899) [5. traffic calculator en equiations](https://www.omnicalculator.com/everyday-life/traffic-density#:~:text=Traffic%20density%20is%20a%20second,road%20of%20a%20length%20L.) ## Use Case: Air Quality Monitoring "Cities in The Netherlands strive to have a clean environment where citizens can enjoy healthy living conditions. To that end cities must keep track of different air pollutants and then try to keep their values in check. The World Health Organization (WHO) specifies the set of parameters that need to be observed to monitor air quality, these are: $PM_{10}$, $PM_{2.5}$, $NO_2$, $SO_2$ and $CO_2$. "[c] Thefore, authorities in a city want to monitor the air pollution and alert citizen when it reachers unsafe levels. So, we ask: - **When does the quality of the air in the district X of the city is reachers an unsave value [b]?** - What **observable properties** of air quality are measured by available air quality sensors on district X? - $PM_{10}$ ($\mu/m^3$), - $PM_{2.5}$ ($\mu/m^3$), - $NO_2$ ($\mu/m^3$), - $SO_2$ ($\mu/m^3$) - $CO_2$ ($\mu/m^3$) - What contextual information is required to define a traffic jam on the road? - save/compliant values for each pollutant [b]. ($>25\mu/m^3$ for $PM_{2.5}$) - The geographic extent of district X - What simple and composite events are needed to define an unsave level of air pollution for dristrict? - $PM_{2.5}$ reading. A sensor within district X reports an a reading. LEVEL 1 - Unsave air quality for district x. Average value of sensors' $PM_{2.5}$ readings per hour. LEVEL 2 ```javascript= // General sintax datasteams /* <datastream> = { << observation_type >> : [ {<observation_name1>: <value_type>}, {<observation_name2>: <value>}, {<observation_namen>, <value>} ], << location >>: [ <feature1>, <feature2>, <featuren>] << time >> : [ <time_instance1>, <time_instance2>, <time_instancen>] } */ // SIMPLE EVENTS: level 1 // pm25_reading = { observation_type: [ {pm25: float } ], // Null -> default all locations location : ['POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))'], time : Null // default any time. // DESIGN: no declaration default to Null }; // Detection rule: None // DESIGN: can detection rules be declared directly on data streams? r1= pm25_reading.pm25 != Null // though, a rule is applied when a location // is defined. // COMPOSITE EVENTS: level 2 usave_level = { observation_type: [ { pm25_reading: object } ], // the extent of the road lane location: Null, time: ['60 min'] // duration // DESIGN: temporal granularity for the computation of the event } // Detection rule // asuming an unsave level > 25 u/m^3 // DESIGN: when the rule applies report the value?? r2 = ( avg(unsave.pm25_reading) >25 ``` ### References [a. EU air quality standards report](https://www.eea.europa.eu/ims/exceedance-of-air-quality-standards) [b. Compliance values air quality](https://www.right-to-clean-air.eu/en/background/deadlines-for-compliance-with-the-limit-values/) [c. Assignment on air quality](https://gip.itc.utwente.nl/exercises/guides/data_analysis/introduction) --- ## Meeting notes ### September 2022 - triffic volume * every reading is an event. * time window: sliding window (size, and sliding_time) - traffic jam - two data streams - defining an event is not a trivial task. - others can extend things follow the example at 3 levels (function services): - pressure sensor is activated. - volume - traffic jam Reason about: **Users:** - 2 types: - User who creates definitions for geographic events. - User who who re-uses event definitions made by other, with few parameter changes. For example apply **relationsship betweed datastreams:** - simple implementation, reduce - campture is the relevance in a data stream, - Focus on reducing the number of implementation funciton and maximazing the number of case coverd by the language. - difference between events - frequency of x event --- ### October, 04 2022 we have an approach to define events, in a piramid fashion. Language allow specify events from the lowests level to the higest level of (different levels of formalization). Experts from other domains can apply the same approach. Don't say they are complete. Build formalizations. Important: - mentioned there must be an expert on the event time, which provide the knowledge for the definition of event. - The language provide a way to define a range of geographic events - How do we extend the language? How to add new operators to the language? - Look for data stream for such a sensors (piezoelectric) ? Regarding Users: - Think of an example that build on the traffic, and add other phenomena (flooding?). Link to decison making (for example, find the way to manage trafic or avoid the traffic jams in the city ). How it is useful for a users (driver). Do not write chapter too case focus! Implementation: - How is the definiton being translated into the architecture components (which operations will be done by which component in the reference architecture). - Work on tranlations to different components. Choose the easier path to, and don't have to implement every case/ operator. Follow up: - Write argumentation for the languge in chapter 4. Use the consideration about users: develo a full application case. Example: routing service to avoid traffic jams. - Look for data sources with piezoelectric sensor for traffic monitoring. - look for data example if no real source is found - The NDW open data for real-time and historic traffic data in the Netherlands - two types of data: measurement data (flow, speed, travel time, queues), and configuration data (metadata about location points and sites). Measurement are computed using various computional methods, such as average speed over a time period or a number of samples, among other. [See basiData element](https://docs.ndw.nu/en/sb/algemeen/element/ElementbasicData_trafficSpeed.html) - report averages for every minute - What kind of sensors does the Nationaal Dataportaal Wegverkeer has? - The NDW collects data from 'providers' (local intities that maitain the measurement sites), that means that a variety of technologies are used to measure traffic. It is not clear if providing infor about the technology is compulsory. But info about that is described using the **mesurementEquipmentReference** or **measureEquipmentTypeUsed** XML elements. The later allows the following types of equipment: | Domainvalue | Description | |---------------| ------------| | anpr | automatic number plate recognition| |bluetooth | passages of Bluetooth equipment| |fcd | floating car data| |infrarood | infrared detection| |laser | laser detection| |lus | detection by [loops](https://diamondtraffic.com/technicaldescription/124) in the road surface| |microwave |microwave detection| |radar | radar detection| |telslang | detection or counting of traffic using a [counter tube](https://traffictechnology.co.uk/blog/portfolio/pneumatic-tube-counter/)| |videodetectie | video detection (with the exception of licence plate recognition/ANPR)| |vri | traffic control system| |datafusie | combination of two acquisition techniques, in which the data has been merged | |overig |any other form of detection or a combination of multiple techniques | - [NDW Documentation](https://docs.ndw.nu/en/avg/index.html): - Traffic datase is store in so called '[Measurement Location Table](https://docs.ndw.nu/en/avg/algemeen/MeasurementSiteTablePublication.html)' - "Flow and speeds are measured at measurement points, and travel times are measured across measurement sites." Measuring sites conatain one or more [measuring points](https://docs.ndw.nu/en/avg/algemeen/meetpunten.html). - Implement language: translations to the architecture and the different components. ## Chapter 4 Structure - Describes the cases for traffic and air quality by using the dataset from the NDW and the KVMI - Then describe the application cases, applying the system (detection of geographic event for smart city applciations). This should point our to the fast that we need some a language - Method: - Using the data structure and purpose of the sensor networks and cases, simulate the sensor netwokr (for example by adding more sensors/stations to the network), The distirubtion of new stations can be defined using semi-random numbers that fill the geographic space (look into that technique use in fedasm) - For simulating data in simulated-stations, rely on snarios relevant for proofing the applicability of the application (i.e. generate events that show that the detecting an processing such event is relevant for traffic management, and air pollution monitoring and reducing risk/exposure.) - Data sources: - https://www.luchtmeetnet.nl/informatie/download-data/open-data - https://data.rivm.nl/data/luchtmeetnet/ - NDW ## Feeeback Chapter 4 **15-03-2023** ### Feedback points - **General comments** - [x] English is difficult to understand - [x] The workd 'despite' is used wrongly - [x] Avoid excuse prases, like ' for the sake of brevity'. Be precise in the writing, brevity has a very low prioty - [x] Many of the stories are build around good arguments, but then they are suddenly dropped which makes them loose it importance. - - **Introduction:** - [x] From the text, it is not clear what the strategy of the chapter is (the purpose of the work in the chapter). - [x] You're calling one thing with two names (app developer and geoinformatic engieers are the same) - [x] What is the goal in taclking the problem of formalisation of events and the proposition of a new DSL? - [x] In other words, it is not clear what is scopte and intension of the chapter (how things add up together?) - [x] When talking about codesign, it is not clear who's involved. Reference to other chapers make it think that now, there is yet another person involve. Geoinformatics engineer and app developers are the same, the other should be an expert in the data or field of application. - [x] Make clear who's involved in the conceptualization and formatilization of events: - concpetualization: data expert - formalization: app developer - [x] The process of defining geographic depend on the **tools** and **data** available to developer and experts - [x] The process of detection geographic events needs: - a formalisation tool - Expert advice on what events are for an application - data available for particular events - Who is involved in the formatilizaiton of events: - data experts, provide insights into the relations between measurement and geographic phenomena. They get to say what measurement mean for a particular phenomena. - Data sources, dictate what it is possible to detect. - Application developer, use data sources and expert's insights to formalise geographic events to be detected in event-driven applications. - [x] The example of 'fire' needs an explanation on the implications of different definitions - [x] On the situion with general EPLs, make a possitive case around their use instead of a negative one. Maybe provide an concrete example regarding the expressivity. - on the topic of EXPRESSIVITY explain that for concept A (pick a good example), it is not possible to express it with other (existing) languages - **Use cases** - [x] Remove applications for examples. Only describe the data - [x] Link use cases to codisign (the involvement of data experts and application developers) - [x] Change the case of 'traffic jam', they are not that relevant. Use the risks of the traffic an flodding instead - - **Formalization (Math)** - [x] Ds? phenomena should be define as a collection of *data streams* - [x] composite events is missing relations (conditionals) - [x] Move granularity to to chapter 3? Better write a complete explanation of granulaity in this chapter. - **Discussion** - [ ] Discribe the souces of uncertainty in the approach of declaring events: - Spatial, given by the distribution of the sensor network - conceptual, given by the assumptions made by the data expert working along with the developer to formalise events of interest. - Temporal, given by the latencies in the sensor network, response time in senseors, and respose time of computing systemes (CEP systems). - [ ] Notice that more sofisticated tessellations tecniques can be applied to sensor networks, and the spatial relations still hold. - [ ] ## Suggestions Chat GPT3 Here's an EBNF for a domain-specific language for declaring geographic events with a syntax similar to **Python**: ```python event_statement ::= "event" event_name ":" event_description event_location? event_date? event_name ::= identifier event_description ::= string event_location ::= "at" identifier event_date ::= "on" date identifier ::= letter (letter | digit | "_")* date ::= year "-" month "-" day year ::= digit digit digit digit month ::= digit digit day ::= digit digit string ::= '"' (character - '"')* '"' digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" letter ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" character ::= letter | digit | "_" | "-" | " " | "." | "," | "!" | "?" | "'" | ":" | ";" | "(" | ")" | "[" | "]" | "{" | "}" | "|" | "/" | "\\" | "@" | "#" | "$" | "%" | "^" | "&" | "*" | "+" | "=" ``` The language allows users to declare a geographic event by using the keyword "event" followed by the event name, description, location, and date. The event name and description are required, but the location and date are optional. The location is specified using the keyword "at" followed by an identifier, and the date is specified using the keyword "on" followed by a date string in the format "YYYY-MM-DD". Identifiers are composed of letters, digits, and underscores, and must start with a letter. Dates are composed of four digits for the year, two digits for the month, and two digits for the day, separated by hyphens. Strings are enclosed in double quotes and can contain any printable ASCII character, including spaces and punctuation. ## Review May 2023 ### Chapter 4 **key:** - :ticket: language syntax - :book: writing - :floppy_disk: implementation Work on the following points: - [ ] Can GeDL can be used to express the second example of wildfire? "there is a wildfire when there is smoke in a location, and the temperature in the location where smoke was detected is **higher than 50 ◦C within five minutes from the first smoke reading.**" :book: > Yes, but for that each observation must be firts declared as a simple event. **Is that possible and concise?** - [ ] Explain better the idea around wildfire, by using the following sentence: "In the first case, a wildfire event is defined by the measurements of smoke and temperature, the conditions on the values reported by sensors for each phenomenon and the conditions **on their spatial and temporal relations.**" :book: - [ ] Change argument around "Sensor data sources such as those mentioned above can be used to detect geographic events that can help avoid risky or dangerous situations in cities and roads if a formal mechanism is available to application developers." [This is not completely true: there are applicaitons that use sensor data and alert of dangerous situation, **but they do it in an ineficient way due to the lack of a formal mechanism**] :book: - [ ] Provide an example using granularty. It is not clear how does it work? What it is useful for. :book: - [ ] Inconsistency on definition of `td` (time), firts is declared as only time formats, but on periodit time `td` uses dates, ex. `td = 7D`. :ticket: - [ ] Definition of **time compounds**, it must include itself. :ticket: - [ ] Include an example in intro to section 4.3. so that the reader understand the statment "GeDL defines a geographic event by declaring datastreams and detection rules". :book: - [ ] El lenguaje me parece una excelente herramienta, pero desde el punto de vista práctico y basado en la descripción del lenguaje y tus propios ejemplos, tengo una duda importante. Si hablamos del caso de uso "ambient-aware running service", uno de los comportamientos indicados es "Notify users about the risk of exposure to air pollution in a segment of the running route, for any event." El contenido en el capítulo 4 parece indicar que para una aplicación de este tipo necesito crear eventos para cada segmento de interés, digamos uno para cada segmento en que podría correr en Enschede, lo cual es poco práctico. Incluso tu axioma 1 "The location of the occurrence of e is defined by a spatial feature resulting from the spatial union of all sensor locations involved in its occurrence" parece reforzar esta idea. Para aclarar esta situación, sería conveniente describir el uso del lenguaje en el contexto de alguno de los casos de uso del capítulo 2. (Este punto está bastante difícil de explicar en texto, si tenés tiempo durante el día podemos discutirlo por llamada) [**See hand-written notes**] :ticket: - [ ] Review the use of the term "expressive". It feels loosly used in the chapter :book: - [ ] What is delivered (useful) to the developer about a detected event? (what is in a notification) :ticket: - [x] Listing 4.1. remove timestamp from keywords - [ ] Implement time operator to enable the declaration of "X occurs within a T time from the ocurrence of Y," is that possible? :ticket: - [ ] How event used in composite event are treated semantically? Do they must take part in a condition? or can we assume that they 'magically' return true whenever they arraive, or set to not null? Listin 4.6 :ticket: - [ ] Check defintion of time pattern in EBNF :ticket: - [ ] What is the purpose of 'spe kle' relation? read about spatial correlations :book: - [ ] Add example using granularity :book: - [ ] Explain thea the purpose of granularity is to reduce the density of sensors :book: #### Javier's Comments - [ ] start all examples with " a domain exprt...", make all examples the same structure. :book: - [ ] reorganise text. :book: - [ ] Search and correct use of relation/relationship :book: - [ ] Look for repearted text (explanaitons) in the chapter and romeve them. :book: - [ ] Focus the content. Every other paragraph you talk abut one subject and then in between you talk about other subjects. that makes it for difficult reading, and lot’s of repetition. Fix this thru the chapter. :book: - For example, you discuss EPL all over the place and every time you bring the subject again you are forced to introduce it, or worse you explain again what it is. The same is true for DSL, and other subjects throughout the chapter. - [ ] Introduction. Topics related to events, and formalisation are explained in an unorganized way (the focus jumb back and forth). Read thru and orginize ideas and text. :book: - [ ] Remove the section of sensor data. It should be integrated with other parts of the text if kept. :book: - [ ] **make a transition following the narrative of the firts part of related work** - [ ] Ex. Fit section on open sensor data into use cases for the language. - [ ] Don't start every section as if it was the first paragraph in the thesis when all is new. :book: - [ ] the purpose of related work is to open the space for the proposed DSL to fall into nicely. The purpose is not to list languages. :book: - [ ] Can we add a disclaimer about quality of data and granularity? :book: - [ ] On expressing duration: - [ ] How about detecting between 23:00 and 01:00. is this a valid duration?. :ticket: - [ ] Make language context awake, the firts time is always the start, and the last time is the end. - [ ] (The NL Alert is triggered the first Monday of the month at 12:00.) Do we have construct for temporal relationships between say two or more durations on different phenomenon? :tiket: - [ ] sensor data section. Re-write section to emphasize the consequences of data formats, the content of sensors (what is reported by sensors), and standards or not that they use to represent the data collected by sensors networks. And How the nature (distribution, quality, etc.) affects the detection for geographic events an therefore the accuracy of event detection :ticket: - [ ] Granularity (formalisation section). **TODO:** detection extent is an attempt to approximate to the occurrence of the event. It has an effect of the quality of notifications (report on occurrence). Add inplications/consequences of using Voronoi tessellations. Explain you are aware of the implications. (add to discussions). Show that you're on control :ticket: - [ ] Spatial relationsships. Figure 4.5. - [ ] What about multiple clusters of clouds, and other relationships? This need to be either included or explained why they were not excluded. :book: - [ ] Clarify that A is any polygon in the diagram and not the same polygon, specially when stating that A touches all other polygos for the 'all' relationship. :book: - [ ] Formalisation of time. - [ ] TODO: What is there in the language and what not? Argue, that small time periods are more relevant than lager ones, and therefore the language emphasize that. Can we define days within a week? This might be useful. Look into how java finds out about the day of the week. :ticket: - Since Java 8, there is a class to represent time in years, months and days, called [Period](https://docs.oracle.com/javase/8/docs/api/java/time/Period.html). This class implements time using the [ISO 8601 Calendar System](https://en.wikipedia.org/wiki/ISO_week_date) - [ ] TODO: disclamer, we don't know in advance the time resolution of the sensor, and how this will impact the detection of events. When detection time is smaller than time resolution of sensor. :book: **Can this be a transition point for the sensor data section** - [x] Which sintactic constructs should be included in GeDL to make it extensible? Adopted strategies: :ticket: - Syntax extensibility via macros (functions) - Modularity and abstractions (modules, apps and namespaces) #### meno-jan - [ ] Menno-Jan. Structure the chapter better. :book: - [ ] MJ. Would be nice to have graphics to illustrathe timelines when explaining the conditions on time. :book: - [ ] MJ. Discussion. Show what GeDL does better or more when compared with other languages, reflect on the features of other languages (example in intro and table.) :book: - [ ] MJ. What about implementation? :floppy_disk: ------------------- ### Conclussions - [ ] The tone of the chapter is more of a summary rather than conclusions. hacen falta argumentos de cierre, conclusiones alcanzadas al finalizar el trabajo. :book: - [ ] Answer the following question directly: what has been learned/discovered for each chapter? - [ ] What are the main conclusions regarding the application of the framework to use cases in chapter 2? are there any relevant points to highlight? :book: - [ ] Read each focus and contributions and draw accurate and solid conclusions. :book: