Matches in ESWC 2020 for { <https://metadata.2020.eswc-conferences.org/rdf/submissions/Paper.155_Review.1> ?p ?o. }
Showing items 1 to 10 of
10
with 100 items per page.
- Paper.155_Review.1 type ReviewVersion.
- Paper.155_Review.1 issued "2001-01-25T14:55:00.000Z".
- Paper.155_Review.1 creator Paper.155_Review.1_Reviewer.
- Paper.155_Review.1 hasRating ReviewRating.2.
- Paper.155_Review.1 hasReviewerConfidence ReviewerConfidence.4.
- Paper.155_Review.1 reviews Paper.155.
- Paper.155_Review.1 issuedAt easychair.org.
- Paper.155_Review.1 issuedFor Conference.
- Paper.155_Review.1 releasedBy Conference.
- Paper.155_Review.1 hasContent "This paper describes the design and implementation of an operator for the SAGE framework that can handle aggregate queries, taking into account the execution model that is used by this framework, which uses the Web preemption model (allowing SPARQL queries to be suspended and resumed so that such queries can be completed even in those cases where in other centralised models there would be a timeout or the convoy effect would appear, and allowing reducing the amount of data transfer that is required by other models like that of Triple Fragments). The paper is well written (only a good number of typos are present, but this does not diminish the understanding) and easy to follow, since concepts are well explained and formalised, and algorithms are well explained and discussed. The approach taken is intuitive, benefiting from the fact that aggregate queries can be easily decomposed (especially in the cases of SUM, MIN and MAX, although with clear approaches to be followed as well for the COUNT and AVG cases). The operator implementation is also made available in GitHub, in a well documented repository that also contains all the data and results, which is highly appreciated by this reviewer. There are only two major aspects that may be improved in the future: - On the one hand, it is not sufficiently clear which are the assumptions under which aggregate queries can be used in this context and where this approach can be applied, since in a footnote there is a mention to the fact that OPTIONALs cannot be used in some parts of the queries. Is this the only restriction for this operator to be applicable? Or are there any other restrictions? The queries used for evaluation are not sufficiently rich to determine whether there may be other options, since they are rather simple and although based on a real use case, the may be very biased towards the generation of Void-like data instead of the typical other cases where aggregates need to be used (e.g., data-warehouse-like queries, like those that can be evaluated on RDF DataCube data). - The experiments are sufficiently well designed, but in my opinion more work may have been put on them: in terms of the variety of configurations for the different approaches presented, in terms of the types of data used and queries evaluated (see above for the discussion on DataCube), and on the usage of usual evaluation and comparison procedures (cold vs warm queries). In any case, the experimentation is sufficient to support the initial claims. However, as an additional point, in the discussion on the comparison in the case of DBpedia, the discussion is not sufficient: there are many comments that are related to the specific implementation of other operators and optimisations that may affect query evaluation time in different systems, which is right, but then it may make somebody think that the comparison is completely unrigurous, since then the comparisons are not applicable at all given the high differences in terms of implementation between different systems. I would have liked to see the behaviour, for instance, under similar general query plans in all systems. - The fragment of DBpedia used is unclearly stated. Some typos: - finally computes --> finally compute - which ables --> which is able - to evaluated --> to evaluate - recombines partial --> recombine partial - a partial aggregations --> a partial aggregation - q5 seems to be missing in the end of the second paragraph of page 9 - PostrgreSQL - supports f projection --> supports projection Note after rebuttal: I acknowledge having read the rebuttal, and as long as those aspects that are repsonded by the authors are considered in the final paper if it is accepted, I would be happy to see this paper accepted."".