Telecon 16.01.2015

From RDF Stream Processing Community Group

Participants

  • Jean-Paul Calbimonte (JP)
  • Peter Wetz (PW)
  • Bernhard Ortner
  • Adrian Paschke
  • Alessandra Mileo
  • Daniele Dell'Aglio (DD)
  • Emanuele Della Valle (ED)
  • Josi
  • Kia Teymourian (KT)
  • Roland Stühmer
  • Sebastian Käbisch
  • Danh Le Phuoc (DL)


Minutes taken by

  • Peter Wetz

Agenda

  • RSP query language: split in smaller queries
  • improved aggregate clause
  • RSP workshop at ESWC

Minutes

RSP query language: split in smaller queries

JPC: JPC shows again the long query of Emanuele

JPC: JPC shows his adapted SRBench queries according to our new syntax over at [1]

PW: JPC, did you find any issues translating the SRBench queries to the new syntax?

JPC: he found some issues, but they are only related to the old queries not because of the syntax. e.g. property paths were mimicking subsumption relationships, and i am not really satisfied with this.

JPC: the separation/categorization of the queries did not really reflect the things we wanted to find out. there should be a query for "rdfs reasoning", another query for "merging multiple streams". in SRBench we did not really call the queries according to the features they test. instead, we called them according to what they do related to the content of the results.

JPC: Moreover DSTREAM is used in a hacky way. It shouldn't be used to detect broken stations.

PW: thanks.

ED: REGISTER STREAM could be done via a lower layer protocol and shouldn't necessarily have to be in the language.

DL: i am against the REGISTER STREAM clause.

JPC: Danh, did you add the LSBench query?

JPC: can you tell us, how successful you were in translating LSBench queries to our current syntax?

DL: (shows LSBench queries of his thesis) [2]

DL: with the current language these queries are quite easy to reproduce.

ED: i propose we should focus on, if we want a notion of ISTREAM, RSTREAM, DSTREAM in the projection clause. i think this is very important.

ED: second, we should discuss, if we want to have a REGISTER STREAM clause.

DL: i think REGISTER STREAM is not necessary. but the R/D/ISTREAM keywords should be there. R/D/ISTREAM can be used like "CONSTRUCT ISTREAM AS [URI]" to give the stream a name

ED: so we agree on a) the FROM NAMED WINDOW ON STREAM, b) putting WINDOWS into the WHERE clause, c) we are agreeing on having R/I/DSTREAM with CONSTRUCT and SELECT, and i seem to be the only one who wants to have REGISTER. we may prefer to put AS after the CONSTRUCT in order to give the output stream a name.

KT: why do we have WINDOW after the WHERE clause. it can also be that you first have the WINDOW, but then the WHERE.

DL: i think that's a bit messy. and i dont really see the difference.

KT: if you look at CQL, you have the windowing first and then the where.

(agreement that our syntax is somehow similar to CQL)

DL: why do we have long keywords like FROM NAMED WINDOW ON STREAM ? it's too long in my opinion and may scare developers away. FROM STREAM would be better.

ED: this limits the reuse of one stream several times in a query, i.e., with different windows.

(long discussion about differences of C-SPARQL or CQELS)

JP: i would be fine with FROM NAMED WINDOW s:1 [...]

DD: proposes: FROM NAMED WINDOW :veryLongWindow ON :s1 [...]

DD: so we remove AS and STREAM

(others agree)

JP: also put the FROM under the CONSTRUCT

ACTION (Daniele): to update the query according to our agreements

ED: to me it's unclear if queries should be able to be registered, i.e., register select queries, which is to register to a continuous dump of select query results

ED: if we remove it, we need to bring it back when we do the protocol. we should not completely forget it.

JP: we should keep it as an optional thing. i am afraid we may forget it in future.

JP: i don't think we have enough time for the rest.

JP: we had 2 more actions. Emanuele to propose graph based count windows, Roland to propose new aggregates.

ED: sorry, i did not have time.

(discussion about I/R/DSTREAM and how it operates on multiple windows)

JP: i think we still have some discussion to do, but since we are running out of time, we postpone it to our next meeting.

ACTION (Roland): Roland to make an improved proposal for avoiding the AGGREGATE clause.

I haven't found a nice way to get rid of the extra AGGREGATE keyword... However, I would add the BIND keyword so that the corresponding line can be parsed with a known syntax and to be more intuitive: 

AGGREGATE {
 GROUP BY ?poi
 BIND (COUNT(?somebody) AS ?howmanycouples)
}


F2F meeting at ESWC

ED: i propose to allow reports to be published. invitation to be an author of the report

ED: or another possibility would be to publish as a column in a semantic web related journal

ACTION (Emanuele): to ask editors of SIGMOD records, if they are willing to publish this, or publish it in the second volume of ESWC proceedings (jp could ask), or publish as a column in a semantic web related journal

DD: proposes to publish our report in the second volume of the ESWC proceedings, which includes the best workshop papers. [3]

DD: maybe jp can ask them to publish a report in the second volume

Actions

  • ACTION (Daniele): to update the query according to our agreements
  • ACTION (Emanuele): to ask editors of SIGMOD records, if they are willing to publish this, or publish it in the second volume of ESWC proceedings (jp could ask), or publish as a column in a semantic web related journal


Open actions from last time, which we still have to address:

  • ACTION (Emanuele): Emanuele to propose graph count based window definition
  • ACTION (Roland): Roland to make an improved proposal for avoiding the AGGREGATE clause. (see above and discuss next time)
  • next meeting: 30.01.2015 15:00CET

Agreements

  • "FROM NAMED WINDOW ON STREAM s:1 [...] AS :veryLongWindow " will be "FROM NAMED WINDOW :veryLongWindow ON :s1 [...] "
  • putting WINDOWS into the WHERE clause, not the other way round
  • introducing R/I/DSTREAM with CONSTRUCT and SELECT (details still to be discussed)
  • keep REGISTER STREAM optional. streams should actually be registered via a protocol and not via the language. but in order not to forget about it, we keep it here for now. if we omit REGISTER STREAM the alternative approach could be to put AS after the CONSTRUCT in order to give the output stream a name.
Retrieved from "https://www.w3.org/community/rsp/wiki/index.php?title=Telecon_16.01.2015&oldid=507"