Semantics of Stream Query Languages Using Ontologies

Overall evaluation
Select your choice from the options below and write its number below.

== 3 strong accept
== 2 accept
== 1 weak accept
== 0 borderline paper
== -1 weak reject
== -2 reject
== -3 strong reject

-1

Reviewer's confidence
Select your choice from the options below and write its number below.

== 5 (expert)
== 4 (high)
== 3 (medium)
== 2 (low)
== 1 (none)

Interest to the Knowledge Engineering and Knowledge Management Community
Select your choice from the options below and write its number below.

== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor

2

Novelty
Select your choice from the options below and write its number below.

== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor

4

Technical quality
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor

4

Evaluation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 not present

4

Clarity and presentation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor

3

Review

The paper provides a novel framework for stream querying with ontologies.
The approach allows for new interesting questions that combine ontology reasoning on stream of windowed ABox triples with questions that range over these different windows.

The framework is powerful as it allows for plug-in of different ontology and query languages. In some parts the definition involves intricacies the reasons of which remain unclear to this reader (see annotated pdf).

The paper has a lot of relevance for semantic web, databases and knowledge representation, but little relevance to knowledge engineering. Hence, I would weakly favour acceptance to the journal (after revision), but not favor acceptance to EKAW

Having read the paper some questions were left unanswered:
+ what are the limitations? What are ontology/query languages that could not be used?

+ I do not understand how the following situation is handled (though it is raised as a problem)
Scenario 1:
T-Box: TempSensor \sqsubseteq \exists _{<= 1} hasTemp.Integer
A-Box: TempSensor(s)
Stream: (s hasTemp 20): t0 (s hasTemp 21): t1

vs

Scenario 2:
T-Box: TempSensor \sqsubseteq \exists _{<= 2} hasTemp.Integer
A-Box: TempSensor(s)
Stream: (s hasTemp 20): t0 (s hasTemp 21): t1

Does the first situation incur an inconsistency? (which is rather problematic for streams) If it does not, why not? (are only languages allowed that are too inexpressive; but then it says that it allows for more expressive ones) And, if it does not, how is scenario 2 handled (where everything is the same but the cardinality constraint)? How can one work practically with two sensor readings when there should be just one?

I would have liked to upload commented PDF. Since this is not possible I have sent it to chairs and authors. The annotations also contain some relevant comments, but it is a major pain to turn them into running text (especially given the lack of page numbers).

Overall evaluation
Select your choice from the options below and write its number below.

== 3 strong accept
== 2 accept
== 1 weak accept
== 0 borderline paper
== -1 weak reject
== -2 reject
== -3 strong reject
0

Reviewer's confidence
Select your choice from the options below and write its number below.

== 5 (expert)
== 4 (high)
== 3 (medium)
== 2 (low)
== 1 (none)
3

Interest to the Knowledge Engineering and Knowledge Management Community
Select your choice from the options below and write its number below.

== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor
3

Novelty
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor
3

Technical quality
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor
4

Evaluation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 not present
1

Clarity and presentation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
== 1 very poor
4

Review

The contributions of the paper are (1) the specification of a two-part
semantics for a previously published streamed query framework called STARQL,
(2) the proof that this framework captures at least the expressivity of
a restricted temporal logic.
I consider both of these results to be relevant to the field.

The main problem I have with this paper is that it is so weakly positioned.
The abstract mentions industrial requirements, which are briefly mentioned
at the beginning of section 4. However, the connection between these
requirements and the formal properties of STARQL are never made explicit.
Why is the two-part semantics a nice feature? I can think of many reasons!
The authors should given their take on this, and not let the reader guess.
The end of section 3 mentions three properties of STARQL w.r.t. the notion of
forgetfulness. This is where, very briefly, it is stated that STARQL allows
more expressive DLs to be used and produces a stream of ABox assertions,
not merely binding. It should be easy to connect those properties
to industrial applications, but this does not happen in the paper.
Moreover, the third property of STARQL, that it requires
"an orthogonal query language" is not argued for at all. It is merely stated.
I believe the authors can do a much better job in this regard,
and should be able to make some changes, if only by adding a single, to-the-point
paragraph in which they relate the distinguishing properties of STARQL to
(industrial) applications.

The weak positioning of the paper also affects the argumentative structure
of the paper, since many of the choices that have been made in developing
the formal framework are not motivated at all.
Take for example the comparison of the two-part semantics to the so-called
"holistic" semantics. This is a core part of the paper, as is claimed in
the abstract and introduction sections, and is clear from the space
allotted to it.
However, the authors do a very bad job in convincing me that this comparison
is interesting in the first place.
At the beginning of section 5 they posit an imaginary critic of the two-part
semantics, who argues that an integrated semantics should be
given instead because "it is not as clear". Since the notion of clarity is not
further explained, I have no idea why section 5 should be in the paper at all.
As with my previous complaints, the authors may be able to solve this problem
by adding a few lines in which they explain the merit of being able to have
an integrated semantics for STARQL over one that is two-part.

A smaller problem is that a lot of the formalisms that are used in the paper
are only slightly incorrect. Luckily, the reader is most of the time able to
deduce the intended formalism from the context. However, it would be nice
if such small errors could be fixed for the final version.
I will give only a few examples of what I mean here:
- In the definition of $\widetilde{\mathcal{A}_{t_i}$,
$ax\langle t\rangle$ should be $ax\langle t_i\rangle$ [p8]
- $ax\langle t\rangle$ is not defined [p8]
- $wS$ should be $ws$ [p8]
- In the definition of $jstr$ the round brackets are misplaced /
should be left out? [p8]
- What is a "pulse declaration"?
Is it the denotation of pulseExpr or of windowExp? [p8]
- $\phi(\boldsymbol{a},\boldsymbol{y})$ should be
$\phi(\boldsymbol{a}_{wh},\boldsymbol{y})$ [p9]
- The definition of $R^{\mathcal{I}_t}$ at the bottom of [p9] is incorrect,
e.g., parameter $\boldsymbol{z}$ occurs only once.
What you want to convey to the reader is that $cert$ takes
a mapping from (vectors of) variables onto (vectors of) constants
and an ontology, and maps onto (vectors of) constants.
More specific, the given ontology `filters' only some of the (vectors of)
constants from the given mapping.
$ECL$ is such a mapping (from vectors of variables onto
vectors of constants).
$R$ is like $cert$, but does not need the ontology parameter,
since it derives the ontology based on a given state,
i.e. $R$ is a mapping from (vectors of) variables and states
onto (vectors of) constants.
I believe that all of these inconveniences are easy to repair
for a final version of the paper.

Overall, I like this paper quite a bit. It is overall well-written and easy
to understand. It has two novel contributions (two-part semantics, relation to
temporal logic). However, in order for this paper to be acceptable as
a full paper I would expect the motivation to be very much improved.

Some minor syntactic errors:
- "depend[s] on" [p1]
- "messages[,] etc." [p5]
- "monotonic[ally]" [p5]
- "fix[e]" [p6]
- "line 13" -> "line 11"? [p6]
- "The simplifications are." ??? [p6]
- "don't" -> "do not" [p6]
- "There must be [a] notion of" [p7]
- "is going [to] be fixed" [p7]
- "ABoxes are [the] joined w.r.t" [p8]
- "let $k'$ [be] the" [p9]
- Unexpected paragraph separator between the two cases described
at the bottom of [p9].
- "integrated [in]to" [p10]
- "may hence [be] considered" [p10]
- "stet" -> "state" [p11]
- "hold[s] at" [p11]
- "answers [answers]" [p14]
- "venture [of]" [p14]

Overall evaluation
Select your choice from the options below and write its number below.

== 3 strong accept
x 2 accept
== 1 weak accept
== 0 borderline paper
== -1 weak reject
== -2 reject
== -3 strong reject

Reviewer's confidence
Select your choice from the options below and write its number below.

== 5 (expert)
x 4 (high)
== 3 (medium)
== 2 (low)
== 1 (none)

Interest to the Knowledge Engineering and Knowledge Management Community
Select your choice from the options below and write its number below.

== 5 excellent
x 4 good
== 3 fair
== 2 poor
== 1 very poor

Novelty
Select your choice from the options below and write its number below.

== 5 excellent
x 4 good
== 3 fair
== 2 poor
== 1 very poor

Technical quality
Select your choice from the options below and write its number below.
== 5 excellent
x 4 good
== 3 fair
== 2 poor
== 1 very poor

Evaluation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
== 3 fair
== 2 poor
x 1 not present

Clarity and presentation
Select your choice from the options below and write its number below.
== 5 excellent
== 4 good
x 3 fair
== 2 poor
== 1 very poor

Review:

The paper presents STARQL, a framework to make OBDA over data streams. The paper is well structured, the authors propose a problem with real use case scenarios, provide a solution its formalisation.

I have a major concern about multi-window queries. In the single-stream case, it is clear that T' is the set of time instants derived by the pulse declaration of the window ws, and everything works fine. In the multi-stream case, T' is not defined: given that each window of the query can have a different sl value, how is T' composed? Is it the union of all the single T'? In that case, please note that every window can close at a different time instant (as it often happens in multi-window queries). So, at the moment the description of the multi-window case is incomplete/wrong, so authors should address it.

A couple of minor concerns that could help to improve the readability of the paper. First, the example at the beginning of section 4 is very hard. I read it multiple times, and I am not still sure that I've got it. I appreciate the fact that is a query from a real-world scenario, but it probably needs more space to be explained (both the textual and the SPARQL-like queries). Second, the syntax section (4.1) explains the simplifications, but not the syntax itself.

Finally, some punctual fixes:
- in Section 2, the sparql-like version is wrong. It should be:
SELECT ?x WHERE{?x :a A AND ?x R ?y} (i.e. ?x R ?y instead of ?y R ?y). Additionally, I don't like :a as symbol for rdf:type. I think you should use a (withous colon) as in SPARQL, or rdf:type (or :type) to make it explicit
- Section 2, A well-mown fact -> a well-known fact
- Section 4, CONSTRUCT operator is used to fixe -> CONSTRUCT operator is used to fix
- Section 4, For every binding for ?s -> For every binding of ?s

Overall evaluation
Select your choice from the options below and write its number below.

== -2 reject

Review
We are not sure whether the concerns of the reviewers can be addressed in the short amount of time before the camera ready version, and therefore have to reject it for the EKAW confernece proceedings. There is also doubt whether it is the right technical level for EKAW, or slightly out of scope.

Based on the reviewers comments we would however strongly encourage you to submit an extended version to the journal.