Jump to content

Telecon 27.11.2014

From RDF Stream Processing Community Group

Participants

  • Kia Teymourian
  • JP Calbimonte
  • Danh Le Phuoc
  • Alasdair Gray
  • Rene Kaiser
  • Alessandra Mileo
  • Maxim Kolchin
  • Adrian Paschke
  • Emanuele Della Valle
  • Mikko Rinne
  • Alejandro Llaves

Apologies

  • Peter Wetz

Minutes taken by

Alasdair

Agenda

  • Comment on hybrid RSP-query from ED . See: here and there
  • Danh: proposal for BGP count windows on the wiki.
  • Oscar: issue of how to handle blank nodes.
  • RSP Workshop

Minutes

Rene Kaiser has recently joined and started following the group to see how it fits with their work.

Comment on hybrid RSP-query from ED

EDV: Put example up on GitHub having problems with conflicting merges. Suggest creating a pool of committers.

JPC: Need to merge all the commits. All the history is available, but you have to go into the history to see who has added what.

EDV: Need a protocol where we can all comment without losing comments

ACTION: Oscar to state what he intended when he suggested we moved the document to GitHub

EDV: went through his motivation for each part of the query

EDV: not sure that the entailment regime makes sense

EDV: Not sure that is makes sense to have window clauses start with 'FROM NAMED STREAM s:1'

EDV: We can consider adding more than just the SEQ operator

EDV: :shortWindow clause used to show different styles of syntax to achieve the same functionality

Roland: Are we going to overload the operators that manipulate timestamps to allow for interval timestamps?

EDV: Suggesting that we adopt C-SPARQL aggregates which do not shrink the results. This is different from the SPARQL 1.1 semantics.

Roland: Would it not be better to use a bind clause to achieve the same functionality and avoid confusion with standard aggregates.

EDV: Not a fan of the syntax, but want to be able to access the variables without shrinking the results.

Danh: Are we not looking to have something that is closer to the SPARQL1.1. syntax and extend?

EDV: We tried this in C-SPARQL and EP-SPARQL but it was not affective

Danh: We will need to define a BNF grammar for the language.

Danh: It is assumed that there is a point in time timestamp

EDV: The three parts of the query rely on different ranges of timestamp: no timestamp, one timestamp or two timestamps

JPC: This relates again to time intervals

Danh: What is meant by WITHIN?

EDV: Using XML Schema for times, e.g. PT4H for a time period of 4 hours

AG: We should make this explicit by typing our statements

Danh: when does the 4 hours begin?

EDV: The start time of the period is the execution time, i.e. relative to NOW. Using the EP-SPARQL interpretation.

Danh: Need to consider the problems that are encountered by delays in a distributed system

EDV: The clause needs a limit (either explicit or implicit) the clause on stream s:1 has an implicit limit of 4 hours, otherwise we would have an unbounded stream problem

Kia: Problem that we are mixing a filtering language and an event processing language. This is what is causing the complication here. Esper language has lots of extensions

Danh: We are making the language very complicated

Alessandra: Complex event processing should be on another level

AG: How about we focus first on a core filtering language and then look at how we can extend or leave complex event processing for an extension?

EDV: Happy to start with a simpler language

Danh: Useful to have some of the language extensions and can be done with something closer to SPARQL1.1. Just identifying keywords. recommend SEQ but not much more. Keep the basic language with stream, windows and graphs.

EDV: First layer without any CEP operators (not even SEQ), second layer with some CEP. CEP don't really use windows

Danh: We have examples of CEP where windows are used

AG: Nothing stops implementers going straight to both layers but having a core without CEP means that those who don't want CEP don't need to worry about it. CEP layer would be an extension of the core model.

EDV: Should the core language allow access to the timestamp?

Roland: Need to consider the underlying model.

EDV: Timestamp does not need to be explicit otherwise an implicit one can be added at

Roland: Time operators will need to be overloaded. Allen's operators will be in the second layer.

EDV: Use the keyword BEGIN rather than AT to access the timestamp.

Alessandro: Second layer is about accessing and manipulating the timestamp.

ACTION: EDV to separate the language into the two layers: core (filtering) and a CEP layer

ACTION: Roland to suggest alternative syntax for aggregate clause

Roland: Quads are not visible in the query.

EDV: Windows give access to the timestamps using the AT keyword

Roland: Want some way of identifying the events that are captured in the stream of graphs.

EDV: Graphs are virtual, patterns in the stream create the event. This way does not require pre-typing. Typing is done at query time.

Roland: Do you need streams of graphs complexity for the core language? It is not really used?

EDV: They are used: putting triples in the graph gives complementarily. Graphs give punctuation

AG: Also gives count windows that make semantic sense

AG: Would be good to have smaller examples of each feature

BGP count window proposal (Danh)

Handling blank nodes (Oscar)

RSP Workshop

AG: Do we want to have a F2F meeting at ESWC?

JPC: Proposal available at https://docs.google.com/document/d/1YjRYnl7TQjs92BkFHqG7wPaEDPN6X4rXGcr80z63e8k/edit#heading=h.5pjpz0g9ndr9

JPC: Idea is to have statements of interest rather than papers

EDV: Make it a full day meeting to give the time that we will need. Can have discussions on event processing, stream processing, ...

JPC: We could make the number of participants larger

Actions

  • ACTION (who?): TODO