Telecon 12.12.2014
Participants
- Jean-Paul Calbimonte
- Alasdair Gray
- Adrian Paschke
- Danh Le Phuoc
- Roland Stühmer
- Shen Gao
- Alessandra Mileo
- Emanuele Della Valle
- Daniele Dell'Aglio
- Monika Solanki
- Peter Wetz
- Oscar Corcho
Minutes taken by
Peter
Agenda
- Revise hybrid RSP-query . See: here
- Actions from last time
- Action: Roland to suggest alternative syntax for aggregate clause
Minutes
Revise hybrid RSP-query
Emanuele: The "under entailment regime" can be moved or removed. He used it for the bidirectional relation in the query, i.e., "is close to".
Emanuele: I left the construct untouched.
Peter: What does the PT mean in the window definition?
Emanuele: See: http://www.datypic.com/sc/xsd/t-xsd_duration.html
Emanuele: It's his proposal to reuse already established definitions, instead of reinventing the wheel.
Peter: +1
Emanuele: Since we removed the SEQ operator we need a way to remove duplicate matches.
Daniele: Proposes that this can be done via a filter statement.
Emanuele: Agrees.
ACTION (Daniele): Daniele to edit the query according his proposal to remove duplicate matches
Danh: coming back to the construct (line 40). ":for (?somebody ?someoneelse)" what does it mean?
Emanuele: It's standard SPARQL. It denotes a collection. It's a shortcut. see: turtle spec
Danh: We should link to our notion of how to define time duration in windows in our final spec.
Roland: How to denote count windows, which count graphs and are not time-based?
ACTION (Emanuele): Emanuele to propose graph count based window definition
Danh: How often should a window be executed/computed? Is this defined (implicitly) in the window definition?
Peter: I think this is related to discussion on the list (see: list-discussion)
Emanuele: We should discuss this later when defining an operational semantics of the language.
General agreement to bring back the WITH DURATION clause (it was removed last time). Without it, we lose too much information on the longwindow.
Roland: What is the use of declaring the graphs in the from clause and later again a second time?
Emanuele: this is standard SPARQL. I was just showing that we support named graphs. So, line 43 "?poi rdf:type" matches the default graph (= FROM GRAPH g:POIs). "FROM NAMED GRAPH g:SocialGraph" creates a named graph which is accessed at the end of the query at "GRAPH g:SocialGraph".
Emanuele: "GROUP BY ?bar" should be "GROUP BY ?poi".
Roland: suggested that we dont need the aggregate keyword. I suggest just to use the group by as is.
Emanuele: [argues for his separate AGGREGATE clause]
Roland: I agree, but I will make a new proposal.
ACTION (Roland): Roland to make an improved proposal for avoiding the AGGREGATE clause
Alasdair: Do we plan to have SPARQL 1.1 aggregates and then some additional extension to support the functionality that Emanuele is proposing?
Emanuele: Good question.
Daniele: In SPARQL 1.1 GROUP BY can not be put in CONSTRUCT query.
Emanuele: Yes, thats right, but there is a workaround. What you do is make a subquery + select and then construct.
Danh: [motivates that we should not introduce too many new operators, because people are still adopting SPARQL 1.1 and they will be confused about our new syntax]
Roland: +1
Monika: +1
Peter: +1
Danh: [proposes an approach where we just have a light-syntax version which can be extended]
Adrian: Another argument for focusing on a core syntax approach is, that it will be much easier to define a precise semantics for it. The more expressiveness we add the harder it will get to define an unambigiqous semantics.
Danh: +1 for Adrian about defining semantics.
Alasdair: +1 for semantics for simple queries.
Monika: Simple queries is the way to go and we should start with real examples.
Alasdair: +1 for keeping SPARQL1.1. queries.
Alasdair: And then having an extended semantics for these non-collapsing aggregates.
Emanuele: We should close the discussion about aggregates. We should support SPARQL 1.1 aggregates.
Oscar: the proposed aggregates of Emanuele are useful. If you have to aggregate twice, which is often the case, this is useful. We should keep these "joint aggregates" in mind.
Alasdair: Proposes to discuss less complex queries, instead of one big query. SRBench queries could be used.
Oscar: Yes, I think that now with this large query having been discussed we can move into more simple queries to provide a better documentation/primer/examples.
Emanuele: Agrees, but SRBench does not include queries with timestamps.
Alasdair: Werent timestamps only part of the CEP extensions?
Adrian: Functions on these timestamps (SEQ, etc.) are, but simple timestamp arithmetics should be in the lower level, i.e., stream processing level.
General agreement: For now focus on several simple SPARQL 1.1 queries (based on queries from benchmarks like SRBench or LSBench) and support SPARQL 1.1 aggregates. Later add more complex semantics ("non-shrinking aggregates" as seen in Emanuele's hybrid query, etc.)
ACTION (Danh): Danh to create LSBench queries on Github. So we have simpler queries.
ACTION (Jean-Paul): Jean-Paul to create SRBench queries on Github.
Alasdair: Please create a folder for SRBench and LSBench, a README with the queries in English and then a file per query
Alasdair: Hopefully we'll then be in a position to define the BNF of the language
next meeting proposed: 16.01.2015
Meeting stopped here after 1h.
Actions from last time
Roland: instead of introducing the AGGREGATE clause (which is completely new)...
AGGREGATE {
GROUP BY ?bar
COUNT(?somebody) AS ?howmanycouples
}
I would rather expand the semantics of BIND to this:
GROUP BY ?bar
BIND(COUNT(?somebody) AS ?howmanycouples)
Actions
ACTION (Daniele): Daniele to edit the query according his proposal to remove duplicate matches
ACTION (Emanuele): Emanuele to propose graph count based window definition
ACTION (Roland): Roland to make an improved proposal for avoiding the AGGREGATE clause.
ACTION (Danh): Danh to create LSBench queries on Github. So we have simpler queries.
ACTION (Jean-Paul): Jean-Paul to create SRBench queries on Github.