Data Portal @ linkeddatafragments.org

Matches in ESWC 2020 for { ?s ?p The paper describes the architecture and technical choices behind Piveau, a platform for creating, sharing, curating and querying Open Data. The authors explain their thinking with respect to the choices made. As can be quickly seen, Piveau tries to attain many different goals, thus there are "many different solutions" and one could, apparently, have envisioned other "combinations of solutions" while still doing something meaningful and interesting. The strong point of the paper, according to me, is the comparison table (Table 1) on page 12. That really shows how the system relates to comparable ones. The strong point of the work itself is that Piveau appears to be the system behind https://www.europeandataportal.eu, with millions of RDF datasets and (the authors state) "tens of thousands of updates per day". I think this level of usefulness and real deployment, alone, would justify acceptance. However, I'm a bit unhappy with the paper *writing*. It starts with the introduction: it is hard to figure out exactly what the problem being solved is, and what the limitations or shortcoming of the state of the art was, before this paper was written. The abstract talks of "barriers" and "limitations...", then of "bodies that encourage and foster...", then states "However, no existing solution for managing Open Data takes full advantage of these possibilities and benefits." This claim is too vague: which possibilities and benefits? I understand that due to the platform having wide applications, it is hard to pinpoint ONE advantage. Yet I still the authors should try to at least rewrite the abstract and introduction to clarify their contribution as much as it can be done. Then, the paper suffers from several typos: "verication", "tenths", "driven. [9]" (the citation should not be outside of the previous phrase to which it belongs), a phrase without a predicate ("For instance the integration of synchronous third-party libraries into our asynchronous programming model.") The authors should really proof-read it thoroughly to catch typos and improve the style. More annoyingly, the paper makes some claims or choices whose reasons or justification are not fully clear: 1. "Furthermore, there is no satisfactory and human-friendly method to present RDF in a user interface." This ignores significant efforts invested in the data visualization community to do just that (present RDF in user interfaces). Other methods are based on RDF graph summarization etc. I understand what the authors had in mind, but the claim here is too broad and needs to be nuanced. 2. The orchestration through PPL (at the end of 4.1) appears to use an ad-hoc model for orchestration, whereas very well-known standards exist for orchestrating Web services (think WSDL or BPML). Why was it necessary to invent something new? 3. The authors state that existing ETL platforms are not developed specifically for RDF. How big of an obstacle is that? Would it have been hard to tweak an existing platform to obtain an RDF-specific ETL one? Overall, I think the paper has value, but it is also annoying in some declarations that appear unjustified. It also suffers from "describing a lot of disconnected aspects" which I think follows from *implementing* a lot of orthogonal aspects. Thus, this second problem may be hard or impossible to solve in the paper. [After reading the authors' rebuttal] It is still not clear to me why micro-services and an ad-hoc orchestration approach is better (more flexible?... why, how?) than the standards in that area. I also find the authors' renewed statement of their contributions not very convincing. However, the paper clearly describes a fair amount of work, I wouldn't fight against acceptance.". }

• Paper.60_Review.1 hasContent "The paper describes the architecture and technical choices behind Piveau, a platform for creating, sharing, curating and querying Open Data. The authors explain their thinking with respect to the choices made. As can be quickly seen, Piveau tries to attain many different goals, thus there are "many different solutions" and one could, apparently, have envisioned other "combinations of solutions" while still doing something meaningful and interesting. The strong point of the paper, according to me, is the comparison table (Table 1) on page 12. That really shows how the system relates to comparable ones. The strong point of the work itself is that Piveau appears to be the system behind https://www.europeandataportal.eu, with millions of RDF datasets and (the authors state) "tens of thousands of updates per day". I think this level of usefulness and real deployment, alone, would justify acceptance. However, I'm a bit unhappy with the paper *writing*. It starts with the introduction: it is hard to figure out exactly what the problem being solved is, and what the limitations or shortcoming of the state of the art was, before this paper was written. The abstract talks of "barriers" and "limitations...", then of "bodies that encourage and foster...", then states "However, no existing solution for managing Open Data takes full advantage of these possibilities and benefits." This claim is too vague: which possibilities and benefits? I understand that due to the platform having wide applications, it is hard to pinpoint ONE advantage. Yet I still the authors should try to at least rewrite the abstract and introduction to clarify their contribution as much as it can be done. Then, the paper suffers from several typos: "verication", "tenths", "driven. [9]" (the citation should not be outside of the previous phrase to which it belongs), a phrase without a predicate ("For instance the integration of synchronous third-party libraries into our asynchronous programming model.") The authors should really proof-read it thoroughly to catch typos and improve the style. More annoyingly, the paper makes some claims or choices whose reasons or justification are not fully clear: 1. "Furthermore, there is no satisfactory and human-friendly method to present RDF in a user interface." This ignores significant efforts invested in the data visualization community to do just that (present RDF in user interfaces). Other methods are based on RDF graph summarization etc. I understand what the authors had in mind, but the claim here is too broad and needs to be nuanced. 2. The orchestration through PPL (at the end of 4.1) appears to use an ad-hoc model for orchestration, whereas very well-known standards exist for orchestrating Web services (think WSDL or BPML). Why was it necessary to invent something new? 3. The authors state that existing ETL platforms are not developed specifically for RDF. How big of an obstacle is that? Would it have been hard to tweak an existing platform to obtain an RDF-specific ETL one? Overall, I think the paper has value, but it is also annoying in some declarations that appear unjustified. It also suffers from "describing a lot of disconnected aspects" which I think follows from *implementing* a lot of orthogonal aspects. Thus, this second problem may be hard or impossible to solve in the paper. [After reading the authors' rebuttal] It is still not clear to me why micro-services and an ad-hoc orchestration approach is better (more flexible?... why, how?) than the standards in that area. I also find the authors' renewed statement of their contributions not very convincing. However, the paper clearly describes a fair amount of work, I wouldn't fight against acceptance."".