Telecon 07.03.2014

From RDF Stream Processing Community Group

Participants

  • Roland Stühmer
  • Alasdair Gray
  • Jean-Paul Calbimonte
  • Claudio Di Ciccio
  • Robin Keskisärkkä
  • Danh LePhuoc
  • Daniele Dell'Aglio
  • Josiane X. Parreira
  • Jesus Arias
  • Darko Anicic

Apologies:

  • Oscar Corcho
  • Avi Bernstein
  • Emanuele Della Valle
  • Axel Polleres

Minutes

  • Jean Paul: Continuing discussion from last week on query requirements in use cases
  • Alasdair Gray: Open Government use case
  • Alasdair Gray: Need for sequential operator
  • jean-paul: Select all companies that double their stock price in one week after they get a contract (this one requires a combination of two streaming data sources, and maybe some relationship between events)
  • Alasdair: reminds me of a river query in semsorgrid
  • Alasdair: Rain on hilltop 15 minutes before rain on the valley
  • jean-paul: window completely in the past, combined with a more recent one
  • Danh: a function to reveal the timestamp
  • Alasdair: Why not use the timestamps in the data
  • Danh: +1 for temporal/ordered operator
  • Roland: you can do that, but it's nice to have the sequence operator built in, as part of the syntax. We can go to a higher level
  • Alasdair: Language could support temporal functions, which may be translated into suitbale queries
  • Darko Anicic: +1
  • Daniele: not only a syntantic problem. in csparql the time is not lost, but preserved
  • Danh: good to define the semantic of this operator, or equivalence as syntactic sugar.
  • Alasdair Gray: We should identify the set of temporal operators that make sense for a data stream
  • Danh: +1 for an action for this
  • Alasdair Gray: Then we can see which ones should be syntactic sugar and which need to be implemented
  • jean-paul: +1 action to identify these operators
  • Daniele: Need to ensure we don't get as complex as EPL
  • Claudio: for the sake of computability, it's perhaps too much. Paz attention to what we are promising. otherwise can be hard to deal with
  • Alasdair Gray: There is a T-SPARQL lanagues which has a very simple set of operators: PRECEDES, =, OVERLAPS, MEETS, CONTAINS
  • Darko: we considered the allen algebra operators: not that complex
  • Darko: not the 'eventual' versions, but the Allen ones are ok
  • Danh: minimal list of operators.
  • Darko: many of those are syntax sugar for the sequence one
  • Alasdair: on which time these operators work?
  • Darko: in this case we are assuming intervals
  • jean-paul: Looking at the figure, displaying the window and the different intervals, that may overlap, be completely inside or outside the window.
  • Alasdair: could envision different semantics
  • Daniele (PoliMI): +1
  • Alasdair Gray: We'd need many different window operators with different semantics
  • Alasdair Gray: This would allow the user to decide the semantics that they want to apply
  • Danh: if you have different operators how do you represent it syntactically
  • Danh: concern in standardization, if there are many options, can incrrease complexity of the language
  • Alasdair Gray: It definitely does increase the complexity
  • Alasdair Gray: But before we standardise and disucss syntax we need to understand the space of possible windows and which ones are maybe core versus more optional
  • Robin Keskisärkkä: +1 (daniele)
  • Daniele: Do we know the end time of an interval whne it starts?
  • Alasdair Gray: Or do we have to wait for some signal that it has ended?
  • Alasdair Gray: That does not support the query 'give me all events that started in the last 5 minutes?'
  • Alasdair Gray: Another semantics would be required for 'give me all events that ended in the last 5 minutes?
  • Alasdair Gray: Another semantics for 'give me all active events?'
  • Daniele (PoliMI): yes, and then there are the combinations: give me the events that started and ended in the last 5 minutes
  • Daniele: perhaps the window is not the right for these queries?
  • Alasdair Gray: Can you give an example?
  • Daniele: windows are very useful with one point timestamps, with intervals, too many combinations
  • Alasdair Gray: Is S = {(G,\tau)} the right model for a stream? SHould it not be a sequence of triples where we know the relationship between the graph URI and the timestamp
  • Alasdair Gray: Note that this does not necessarily solve the logistics use case problem where the timestamps are within the graph G.
  • Alasdair Gray: I am suggesting S = {(G, p, \tau)} where p is a predicate that relates the grpah URI to the timestamp
  • Alasdair Gray: Dahn suggests that we coud have the graph streaming and use the timestamp within the data
  • Alasdair Gray: Is a stream a sequence of quads where each triple has its context with it; we could also have a metadata stream that annotates the contexts with timestamps?
  • Josi: perhaps too complicated, may be too hard when we come to define semantics
  • jean-paul: to work on the proposed Action, to identify other operators including based on Allen's, and see if they are syntactic sugar for others. Also analyze and send around Alasdair proposal for the graphs.