View source for Telecon 17.01.2014

==Participants==

*Emanuele Della Valle
*Axel Polleres
*Payam Barnaghi
*Jean-Paul Calbimonte
*Daniele Dell'Aglio
*Josiane X. Parreira
*Jesus Arias
*Darko Anicic 
*Danh Le Phuoc
*Monika Solanki
*Roland Stühmer
*Robin Keskisärkkä
*Alejandro Llaves
*Alessandro Margara
*Sebastian Kaebisch

Apologies:

*Oscar Corcho
*Darko Anicic
*Manfred Hauswirth


==Minutes==

===Use cases and RSP Query requirements===

*Jean-Paul: Hello Everybody, nice to see you this year
*Jean-Paul: Progress on use cases description. Still to complete query examples on every use case.
*Emanuele: I can try to add queries to the use cases I authored
*Jean-Paul: Features and extensions in existing RSP query processors might be interesting to look at. 
*Emanuele: Propose to use the SRBench table as a start, to check which systems implement which features.
*Roland: +1 for using SRBench as a start
*Emanuele: start form SRBEnch table
*Jean-Paul: update SRbench table on wiki
*Danh: is SPARQL no already covering most of the requirements?
*Danh: query asking dealing with uncertainty: can SPARQL address this?
*Jean-Paul: exactly, many use cases not covered by SPARQL, we need use cases queries to show this.
*Claudio: in our 3 use cases SPARQL does not really match our requirements
*Josi: check use cases, see the support? which existing extensions support which use cases
*Axel Polleres: +1 to a) extend use cases by informal queries b) check use cases against frameworks/languages
*Jean-Paul: ACTION: all use cases providers to update sample queries: http://www.w3.org/community/rsp/wiki/Use_cases
*Emanuele: like to see queries we cannot answer with current languages
*Josi: real cases in the wiki, interesting to have new cases from a wider audience
*Axel Polleres: as an action to all use case providers?
*Jean-Paul: yes, action to use case providers
*Danh: express the queries in use case, if there is an issue, solve together
*Axel Polleres:but probably it would need the language/systems providers to check which ones they can tackle/how and which not and why
*Axel Polleres:...on the other side
*Jean-Paul: ACTION: language providers to check which ones they can(not) tackle and why

===RSP Query Features + extensions===
*Jean-Paul: Sharing screen, SRBench query features: [http://iswc2012.semanticweb.org/sites/default/files/76490625.pdf]
*Axel Polleres: I see that screen
*Jean-Paul: Features provided by (some) RSP early implementers
*Danh: put cep and stream processing in the same query patterns?
*Jean-Paul and Danh to share their previous analysis of supported queries/features.
*Danh: Mixing features of both CEP and Continuous queries can be really too complicated
*Emanuele: tend to agree. Only EPL seems to be CEP and Continuous query processing language
*Emanuele: but it's very complex
*Emanuele: not necessarily mix CEP with continuous
*Roland: sometimes CEP not completely defined. Maybe a subset: e.g. seq operators
*Alessandro Margara: agree with Emanuele. Languages that offer both CEP and continuous queries are very complex.
*Monika: can we integrate EP-SPARQL with contonuous extension of SPARQL
*Josi: Discussion: Add set of features that are needed in the usecases. No need to support the full features of other paradigms, like CEP
*Emanuele: whether if you evaluate standard SPARQL on streaming graphs, you can have an answer
*Roland: Monika: EP-SPARQL is itself an extension to sparql, so no problem in cluding it
*Emanuele: the windows is somehow a way to select triples without knowing the graph name
*Roland: the stream semantics must be obeyed, though

===TODO and requirements discussion===
*Axel: action: use case provider: describe queries informally
*Axel: + for some use cases: we can see the which use cases can be handled by current languages
*Emanuele: for those who have use cases, we already have queries and how to solve them, but we need more examples from a wider audience
*Emanuele: nice to have more. but maybe little value if we only use the queries already present in current papers
*Axel: Implementers can show a link to paper that shows how it can be done
*Claudio: i feel on the outside. Happy to contribute
*Caludio: but need to understand mechanism to describe requirements
*Jean-Paul: Feel free to add your queries
*Emanuele: Action: put the table of features in the wiki
*Roland: not standard and set oriented operators not present in the table, needed in use cases in EP SPARQL
*Roland: Sequence, disjoint, interval wise
*Monika:I can provide some more examples of event operators which could be useful
*Monika: *outside EP-SPARQL
*Axel :will also try to provide some more abstract (corner case) use cases :-)
*Emanuele: recently discussing multi stream querying
*Axel: Emanuele digging up some problem on efficiency on querying multiple streams or multiple windows on the same stream...
*Axel: come up with weird ideas and corner cases
*Jean-Paul: We have info on current implementations and languages: [http://www.w3.org/community/rsp/wiki/RDF_Stream_Processors_Implementation]
*Danh: Action : Danh to put use cases with muliple windows on one stream and multiple streams (variable on stream URI)
*Jean-Paul: ACTION: Emanuele,JP: update wiki page: homogenize, references


==Actions==

*Use case providers: describe queries informally in use case page [http://www.w3.org/community/rsp/wiki/Use_cases]
*RSP language/processors providers: check which queries can be handled (or not) by current languages and how
*JP, Emanuele:  update wiki page on RSP implementations and languages: homogenize, references