# Semantics of Stream Query Languages Using Ontologies

### Tracking #: 726-1936

Responsible editor:
Guest Editors EKAW 2014 Schlobach Janowicz

Submission type:
Conference Style
Abstract:
In order to satisfy the industrial requirements of processing dynamic knowledge from possibly heterogeneous sources, various query languages have been proposed which aim at lifting the relational stream query languages to the ontological/semantic layer. Most of the languages adapt important relational stream operators such as sliding window operators to this layer. But the adaptation and the semantic specification of the stream operators is not trivial due to the additional entailments and constraints w.r.t. ontologies. In this paper, we discuss the semantics of the new query-language framework STARQL (Streaming and Temporal ontology Access with a Reasoning-Based Query Language) in comparison to other stream-temporal query languages and provide results stating its connections to the semantics for temporal logics over ontologies.
Full PDF Version:
Tags:
Reviewed

Decision/Status:
[EKAW] reject

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 26/Aug/2014
 Suggestion: [EKAW] reject Review Comment: 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).
Review #2
Anonymous submitted on 02/Sep/2014
 Suggestion: [EKAW] conference only accept Review Comment: 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]
Review #3
Anonymous submitted on 03/Sep/2014
 Suggestion: [EKAW] combined track accept Review Comment: 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
Review #4
Anonymous submitted on 11/Sep/2014
 Suggestion: [EKAW] reject Review Comment: 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.