Telecon 12.06.2015

From RDF Stream Processing Community Group

Participants

  • Jean-Paul Calbimonte (JPC)
  • Danh Le Phuoc (DLP)
  • Adrian Paschke (AP)
  • Josi Xavier Parreira (JXP)
  • Minh Dao-Tran (MDT)
  • Peter Wetz (PW)
  • Daniele Dell'Aglio (DDA)
  • Robin Keskisärkkä (RK)
  • Tara Athan (TA)
  • Fariz Darari (FD)
  • Javier Fernandez (JF)
  • Alejandro Laves (AL)

Regrets

  • Emanuele Della Valle (EDV)

Minutes taken by

  • Peter (PW)

Agenda

  • Update on query semantics
  • CEP: next steps
  • Evaluation and Benchmarks: next steps
  • Recent discussions
    • Identify a time vocabulary (cf. [1])
    • Interplay of timestamped graph predicate with stream order and time-bounded substreams (cf. [2])
    • Multiple graphs with the same timestamp (cf. [3])?
    • Naming of our concepts (cf. [4])
    • Timestamps vs. Intervals (cf. [5])

Resources

Minutes

Update on query semantics

Timestamps vs. Intervals

JPC: Avi raised the point in time issue on the mailing list (cf. [6]). The model already allows to define time-intervals. But for later (precise definition of the semantics) we will only focus on point in time.

MDT: We should not close the possibility to define intervals.

ACTION: JPC to state on the Github-Page of our definitions ([7]) that our model works for point in time semantics, but that it's possible to extend our model to time interval semantics.

Multiple graphs with the same timestamp

JPC: We should remove "There can be multiple graphs with the same timestamp.". We can have multiple triples, but they should always be in the same graph.

DDA: I agree, but how would it look like if we have interval-based semantics for graphs?

(no detailed answer is given)

RK: How to consider graphs which happen at the same time due to the granularity of timestamps? E.g. if granularity is low then it is more likely that two graphs happen at the same time.

(no clear answer given)

Identify a time vocabulary

This should contain predicates explaining that a graph was generated at time t. Generally: Predicates that indicate the notion of time.

DDA: Why we don't use the time ontology?

PW: Alasdair describes on github why the time ontology is not enough [8].

TA: What does it mean "p is a predicate that captures the relationship between the time instant t and the graph g"? If it is actually a predicate (e.g. a relation), then why is it indexed?

JPC: example: p can be "was generated at", etc.

ACTION: PW to create a first draft of the vocabulary on Github and start discussion.

RK: I think a simple example would be good here, using two separate time properties in the same stream, e.g. generatedAt and createdAt. Just to see how multiple timestamps would be handled.

ACTION: RK to add a simple example to see how multiple timestamps will be handled (see above comment by RK).

ACTION: JPC to add "If two graphs in the stream have the same timestamp, then they must have different predicates." to our definitions.

ACTION: JPC to add to our definition of a stream that a stream is ordered based on t and a given p.

Naming of our concepts

(discussion about renaming "bounded substreams" to "window" (refering to CQL))

ACTION: JPC to do: when we define "bounded substreams" we add a sentence stating that this is a similar concept to "window" from CQL.

ACTION: MDT to ammend the definitions of bounded substreams on github.

MDT: i think that count-based and time-based substreams take away some responsibility from the engine. Imho time- and count-based should not be defined here. We just need the notion of (bounded) substreams and then later on we add window-functions or operators that return a substream satisfying certain properties, and then this function will return an according substream.

ACTION: all to discuss proposal of MDT (above).

JPC: we have still some confusion about the operators and the concept of substreams.

CEP: next steps

JXP: We did not work on any new actions, but we will create a new subwiki for the CEP part and revise the use cases according to SCEP.

JPC: Okay, thanks for the report. It would be nice to have an update on requirements and use cases related to SCEP and to maybe create a separate wikipage for it to get it started.

ACTION: JXP to update requirements and use cases of SCEP via a separate wikipage.

Evaluation and Benchmarks: next steps

AL: proposes to move the table from the slides to the wiki so that everyone can add and edit new metrics and features that are important to evaluate

ACTION: AL to create a wikipage containing the table frome the slides [9].

Misc

JPC: i talked to Sebastian Käbisch who was leading the RSP serialization group. Sebastian proposed to catch up with what is currently going on at the Web of Thinks Working Group.

ACTION: JPC to get a link to the Serialization work of the Web of Things WG from Sebastian.

Next phone call

  • 26.06.2015

Actions

  • ACTION: JPC to state on the Github-Page of our definitions ([10]) that our model works for point in time semantics, but that it's possible to extend our model to time interval semantics.
  • ACTION: PW to create a first draft of the vocabulary on Github and start discussion.
  • ACTION: RK to add a simple example to see how multiple timestamps will be handled.
  • ACTION: JPC to add "If two graphs in the stream have the same timestamp, then they must have different predicates." to our definitions.
  • ACTION: JPC to add to our definition of a stream that a stream is ordered based on t and a given p.
  • ACTION: JPC to do: when we define "bounded substreams" we add a sentence stating that this is a similar concept to "window" from CQL.
  • ACTION: MDT to ammend the definitions of bounded substreams on github.
  • ACTION: all to discuss proposal of MDT (above).
  • ACTION: JXP to update requirements and use cases of SCEP via a separate wikipage.
  • ACTION: AL to create a wikipage containing the table frome the slides [11] -> DONE.
  • ACTION: JPC to get a link to the Serialization work of the Web of Things WG from Sebastian.