Telecon 27.02.2015

Participants

Regrets

Minutes taken by

Actions from last time
- ACTION (JPC): to post the github link for queries and create readme file with possible data sources
- ACTION (all): each should come up with 2 queries. each query should use at least 2 input sources (taxi data + anything else (nyc open data, e.g., weather, traffic))
- ACTION(RS): make an example starting from the discussion
- ACTION(EDV): to invite Danh in the GitHub RSP group

Please add links to any datasets/resources related wiki pages

JPC: shows query page: https://github.com/streamreasoning/RSP-QL/blob/master/RSP-QL%20Sample%20Queries.md
AG: units?
JPC: good question. this poses a bigger problem, i.e., what is the data model? I made an example, but we definitely need a common date model, which we dont have, yet.
AG: i think the same goes with the date timestamps

Query 2 + 3

AM: explains her first query. it is outputting the location whenever there are more than 20 taxis that drop off at the same location.
EDV: there is a notion of cells/grid in the taxi data.

(discussion about how to encode this in the sparql query)

EDV: we dont want GEOSPARQL functions in a streaming setting since they are computationally intense. so we precompute the grid and decorate the dropoffs/pickups with the cells, e.g., :dropoff1 :isInCell :cell1
AM: explains query 3. it uses aggregates which we dropped in a previous call.

Query 4

BO: explains query 4. it showcases the possibility of using 2 streams and 2 windows.
EDV: pickup stream from first one (DSTREAM query) and then similar then current query without the constraints because we know that the first input stream is delayed.
AM: would it be possible with 1 window?
EDV: that would be possible with the from AG proposed "windows in the past" which would be even nicer.

Query 5

Query 6

JPC: i like the idea of FILTER NOT EXISTS. however, we do not have the traffic light data in the dataset.
FD: taxi which did not have to stop at any red traffic lights. i modified the data model a bit to store the traffic signals. there are some differences between the graph and triple data model.

Query 7

PW: explains query 7.
EDV: we define a grid which is small enough. and decorate our data with it. and
PW: features
AG: EDV did we agree on not bringing in geosparql queries?
EDV: no, not really. my group did attempt to integrate our own geosparql adaption. we also attempted to integrate strapon. but generally speaking it destroys reactiveness. a very simple query of strapon takes a few seconds
AG: how does putting it on a grid affect this?
EDV: you come up with this grid and ids. i will point you to a paper where we explain this.
AG: can we think of geosparql as an extension for our work?
EDV: i think this would be good research to make geosparql fitting for stream processing use cases.
PW: is this grid computation done during run time of a sparql query?
EDV: for static knowledge (e.g. neighbourhood data) you will precompute it. for stream data (which mostly is point data) it is computationally easy to do it. you just do it directly on the stream and then add the info as a triple and then stream it to the engine.

question by peter: how to combine window data with other data? e.g. from geonames

ACTION: jpc makes a first attempt at writing the schema for the data model (EDV is willing to help with the grid stuff)
ACTION: BO to change his queries according to discussion
ACTION: all who contributed: which feature do they showcase with their query + fixing of queries.
ACTION: all who did NOT contribute: please contribute (feel free to take any of the queries from the bullet list) especially if there is still a feature, which is not covered, yet.

summarize agreements here, if any were made