Matches in ESWC 2020 for { ?s ?p === After rebuttal === I thank the authors for their rebuttal and have improved my score accordingly. ----- I discuss the review criteria of the track: === Relevance to the track === This track or the Industry track are the right targets of this paper. === Rigor in the methodology and analysis used to reach conclusions === I am not saying that the authors did not use rigor, but in the paper they did not provide too many rationale for their decisions, eg. * "we analyzed existing solutions for suitability. And in the Brick ontologies, we found the most suitable candidate..." What were the criteria, which were the other candidates? * The authors use Semantic Tagging, which is not a particularly well-defined technical term, or a term I encountered often in the SW community. Sometimes what in other work is being presented as Semantic Tagging looks like sloppy modelling tailored to facilitate some sort of retrieval. What is the use of Semantic Tagging use in the project? In other projects, Semantic Tags are assigned to unstructured data with the aim of adding some sort of structure. Given that you use semistructured data anyway, why not model more elaborately? === Originality === A lot of the things the authors use have been around, but are nicely combined by the authors. If not there, novelty could be found I think in the embedding into the workflow and the solution. There was an Industry talk at Semantics 2019 on Semantics and BIM https://2019.semantics.cc/role-semantics-googles-smart-building-platform === Usefulness to developers, researchers, and practitioners === The paper reads a bit like a technical case study. So the paper is most useful to practitioners I think. === Significance of the problem addressed === Increasing the energy efficiency of buildings is relevant. === Value of the use case in demonstrating benefits/challenges of semantic technologies === The paper shows the benefits of semantic technologies to the use case. === Adoption by domain practitioners and general members of the public === The paper reports on the case of one building of the authors' company. There is no evidence of adoption outside of this one building. === Impact of the solution, especially in supporting the adoption of semantic technologies === The solution has the potential to further the uptake of semantic technologies in the building domain. === Applicability of the lessons learnt to other use cases === Lessons learnt can be found in section 4, but the section is not marked as lessons learnt. The lessons learnt should be applicable in other domains. === Readability, Clarity and quality of the description === * The paper reads well * Section 3 could be restructured: ** Why is related work (3.1) a subsection of Section 3 and not a section on its own? ** Similarly, "Brick Criticism and Recommendations" could be factored out into a lessons learnt or discussion section * I printed the paper. A lot of the figures have a fairly tiny font, Fig. 8 has the smallest and is barely legible. * I find the symbols and colours used in Fig. 1 are hard to understand. Why is REST dark blue and SPARQL light blue? How do the components communicate with the triple store (is it only Data Ingestion that uses SPARQL and only sometimes)? Do the number indicate the workflow? Maybe the use of standardised symbols, eg. from the UML component diagram, could make this figure easier to follow. * What is the difference between "Knowledge Graph" "Dataset" (residing in Jena, according to Fig. 1) and RDF Graph or RDF Dataset? * The authors did not give the specific prefix definitions, rather they say that they are from the Brick ontology. The presentation of the actual prefixes could help in determining which version of the Brick ontology the authors use. * The third dimension in Fig. 3 - what does it mean? ==== Typos: ==== * Let`s -> Let's (p. 11) ==== Verdict ==== The case presented in the paper is interesting and would deserve acceptance. However, the paper could benefit greatly from: * emphasizing the novel part, that is how semantics is embedded in the solution and how and how the solution is embedded into the workflow * restructuring Section 3". }
Showing items 1 to 1 of
1
with 100 items per page.
- Paper.102_Review.2 hasContent "=== After rebuttal === I thank the authors for their rebuttal and have improved my score accordingly. ----- I discuss the review criteria of the track: === Relevance to the track === This track or the Industry track are the right targets of this paper. === Rigor in the methodology and analysis used to reach conclusions === I am not saying that the authors did not use rigor, but in the paper they did not provide too many rationale for their decisions, eg. * "we analyzed existing solutions for suitability. And in the Brick ontologies, we found the most suitable candidate..." What were the criteria, which were the other candidates? * The authors use Semantic Tagging, which is not a particularly well-defined technical term, or a term I encountered often in the SW community. Sometimes what in other work is being presented as Semantic Tagging looks like sloppy modelling tailored to facilitate some sort of retrieval. What is the use of Semantic Tagging use in the project? In other projects, Semantic Tags are assigned to unstructured data with the aim of adding some sort of structure. Given that you use semistructured data anyway, why not model more elaborately? === Originality === A lot of the things the authors use have been around, but are nicely combined by the authors. If not there, novelty could be found I think in the embedding into the workflow and the solution. There was an Industry talk at Semantics 2019 on Semantics and BIM https://2019.semantics.cc/role-semantics-googles-smart-building-platform === Usefulness to developers, researchers, and practitioners === The paper reads a bit like a technical case study. So the paper is most useful to practitioners I think. === Significance of the problem addressed === Increasing the energy efficiency of buildings is relevant. === Value of the use case in demonstrating benefits/challenges of semantic technologies === The paper shows the benefits of semantic technologies to the use case. === Adoption by domain practitioners and general members of the public === The paper reports on the case of one building of the authors' company. There is no evidence of adoption outside of this one building. === Impact of the solution, especially in supporting the adoption of semantic technologies === The solution has the potential to further the uptake of semantic technologies in the building domain. === Applicability of the lessons learnt to other use cases === Lessons learnt can be found in section 4, but the section is not marked as lessons learnt. The lessons learnt should be applicable in other domains. === Readability, Clarity and quality of the description === * The paper reads well * Section 3 could be restructured: ** Why is related work (3.1) a subsection of Section 3 and not a section on its own? ** Similarly, "Brick Criticism and Recommendations" could be factored out into a lessons learnt or discussion section * I printed the paper. A lot of the figures have a fairly tiny font, Fig. 8 has the smallest and is barely legible. * I find the symbols and colours used in Fig. 1 are hard to understand. Why is REST dark blue and SPARQL light blue? How do the components communicate with the triple store (is it only Data Ingestion that uses SPARQL and only sometimes)? Do the number indicate the workflow? Maybe the use of standardised symbols, eg. from the UML component diagram, could make this figure easier to follow. * What is the difference between "Knowledge Graph" "Dataset" (residing in Jena, according to Fig. 1) and RDF Graph or RDF Dataset? * The authors did not give the specific prefix definitions, rather they say that they are from the Brick ontology. The presentation of the actual prefixes could help in determining which version of the Brick ontology the authors use. * The third dimension in Fig. 3 - what does it mean? ==== Typos: ==== * Let`s -> Let's (p. 11) ==== Verdict ==== The case presented in the paper is interesting and would deserve acceptance. However, the paper could benefit greatly from: * emphasizing the novel part, that is how semantics is embedded in the solution and how and how the solution is embedded into the workflow * restructuring Section 3"".