Matches in ESWC 2020 for { ?s ?p ?o. }
- Author.101.2 withRole PublishingRole.
- Author.101.2 isHeldBy Jianmin_Han.
- b0_g269 first Author.101.3.
- b0_g269 rest b0_g270.
- Author.101.3 type RoleDuringEvent.
- Author.101.3 label "Xin Yao, 3rd Author for Paper 101".
- Author.101.3 withRole PublishingRole.
- Author.101.3 isHeldBy Xin_Yao.
- b0_g270 first Author.101.4.
- b0_g270 rest nil.
- Author.101.4 type RoleDuringEvent.
- Author.101.4 label "Juan Yu, 4th Author for Paper 101".
- Author.101.4 withRole PublishingRole.
- Author.101.4 isHeldBy Juan_Yu.
- Qi_Liu type Person.
- Qi_Liu name "Qi Liu".
- Qi_Liu label "Qi Liu".
- Qi_Liu holdsRole Author.101.1.
- Jianmin_Han type Person.
- Jianmin_Han name "Jianmin Han".
- Jianmin_Han label "Jianmin Han".
- Jianmin_Han holdsRole Author.101.2.
- Xin_Yao type Person.
- Xin_Yao name "Xin Yao".
- Xin_Yao label "Xin Yao".
- Xin_Yao holdsRole Author.101.3.
- Juan_Yu type Person.
- Juan_Yu name "Juan Yu".
- Juan_Yu label "Juan Yu".
- Juan_Yu holdsRole Author.101.4.
- Author.102.1 type RoleDuringEvent.
- Author.102.1 label "Henrik Dibowski, 1st Author for Paper 102".
- Author.102.1 withRole PublishingRole.
- Author.102.1 isHeldBy Henrik_Dibowski.
- b0_g272 first Author.102.2.
- b0_g272 rest nil.
- Author.102.2 type RoleDuringEvent.
- Author.102.2 label "Francesco Massa Gray, 2nd Author for Paper 102".
- Author.102.2 withRole PublishingRole.
- Author.102.2 isHeldBy Francesco_Massa_Gray.
- Henrik_Dibowski type Person.
- Henrik_Dibowski name "Henrik Dibowski".
- Henrik_Dibowski label "Henrik Dibowski".
- Henrik_Dibowski holdsRole Author.102.1.
- Francesco_Massa_Gray type Person.
- Francesco_Massa_Gray name "Francesco Massa Gray".
- Francesco_Massa_Gray label "Francesco Massa Gray".
- Francesco_Massa_Gray holdsRole Author.102.2.
- Paper.102_Review.0_Reviewer type RoleDuringEvent.
- Paper.102_Review.0_Reviewer label "Anonymous Reviewer for Paper 102".
- Paper.102_Review.0_Reviewer withRole ReviewerRole.
- Paper.102_Review.0_Reviewer withRole AnonymousReviewerRole.
- Paper.102_Review.0 type ReviewVersion.
- Paper.102_Review.0 issued "2001-02-03T05:34:00.000Z".
- Paper.102_Review.0 creator Paper.102_Review.0_Reviewer.
- Paper.102_Review.0 hasRating ReviewRating.1.
- Paper.102_Review.0 hasReviewerConfidence ReviewerConfidence.5.
- Paper.102_Review.0 reviews Paper.102.
- Paper.102_Review.0 issuedAt easychair.org.
- Paper.102_Review.0 issuedFor Conference.
- Paper.102_Review.0 releasedBy Conference.
- Paper.102_Review.0 hasContent "This paper describes a case study of constructing a knowledge graph for the building automation systems (BAS). The proposed work extends the Brick ontology and integrates some other ontologies to define a comprehensive vocabulary to describe various requirements and operations of automatically operating a building, in particular its HVAC system. Positives: + The paper fits very well with the conference. + The paper is well-written and easy to follow. + The examples presented throughout the paper are especially helpful in making the contributions concrete. Negatives: - The paper lacks in-depth technical discussions on the employed vocabularies and techniques. For example, I was really looking forward to seeing a detailed discussion on "transformations and calculations" using SHACL rules in Section 4, as described in the end of Section 2. However, there is no such technical discussions at all. - There is no discussion on the values realised through this proposed knowledge graph, which has apparently been commissioned and deployed in a building. Without this discussion it is hard to evaluate the practical contributions made by this paper. Detailed comments: * The figures are not clear or large enough to be seen clearly. * Many of the figures are used to present fragments of the ontology or the knowledge graph. Instead of showing them as UML-like figures, I suggest actual definitions of these classes, for example in the DL syntax or the Manchester syntax, which is more precise and also appropriate for the ESWC community. * Pg. 5, end of 1st paragraph of Sec. 3.1, "a in the meanwhile" is wrong. * Pg. 6, where are the green arrows that are supposed to represent imports relationship? I can't see them. ====================== I thank the authors for providing the rebuttal. The rebuttal does not really address the questions raised by myself and the other reviewers. It is more a promise of what to add/address in the revision. Hence, I've decided to keep my original score."".
- Dnyanesh_Rajpathak type Person.
- Dnyanesh_Rajpathak name "Dnyanesh Rajpathak".
- Dnyanesh_Rajpathak label "Dnyanesh Rajpathak".
- Dnyanesh_Rajpathak holdsRole Paper.102_Review.1_Reviewer.
- Dnyanesh_Rajpathak mbox mailto:dnyanesh.rajpathak@gm.com.
- Paper.102_Review.1_Reviewer type RoleDuringEvent.
- Paper.102_Review.1_Reviewer label "Dnyanesh Rajpathak, Reviewer for Paper 102".
- Paper.102_Review.1_Reviewer withRole ReviewerRole.
- Paper.102_Review.1_Reviewer withRole NonAnonymousReviewerRole.
- Paper.102_Review.1_Reviewer isHeldBy Dnyanesh_Rajpathak.
- Paper.102_Review.1 type ReviewVersion.
- Paper.102_Review.1 issued "2001-01-15T14:03:00.000Z".
- Paper.102_Review.1 creator Paper.102_Review.1_Reviewer.
- Paper.102_Review.1 hasRating ReviewRating.2.
- Paper.102_Review.1 hasReviewerConfidence ReviewerConfidence.4.
- Paper.102_Review.1 reviews Paper.102.
- Paper.102_Review.1 issuedAt easychair.org.
- Paper.102_Review.1 issuedFor Conference.
- Paper.102_Review.1 releasedBy Conference.
- Paper.102_Review.1 hasContent "1. The state-of-the-art is either limited or incomplete. Moreover, the author did not mention the gaps in the existing literature which motivated this work. 2. To me, this work is low on novelty but high on application specific use of existing technology. Given this, the authors need to explain clearly the biggest challenges in dealing with real-world BAS. 4. In Introduction, Section 1, state clearly the existing approaches to BAS, what are the limitations of existing approaches, how the proposed approach bridges the gaps observed in existing approaches, what are the key contributions of your work. Finally, please provide how the paper is organized. 5. There is no need of a footnote 1. Its already explained in Section 1. 6. The authors need to give further technical details of a knowledge graph. How the knowledge graph is designed? How the performance of a knowledge graph is evaluated? 7. Data Ingestion, 2nd paragraph, "The IFC file is then automatically converted to ifcOWL..." How is it automatically converted? Please provide details of parser used? 8. Data Ingestion, 2nd paragraph, are the triples indexed while storing them into a database? Please provide example of triples. How the metadata used for triples is designed or from which standard it is used? How often the semantic model requires update? 9. Generally, the semantically annotation information is rich in its knowledge representation and capture, but such knowledge graphs can be very slow to execute with increases scale of data (particularly gathered in real-world application). Please state how computationally efficient is the performance of your knowledge graph when employed to solve real world applications. 10. Please improve the quality of figures to make them readable. 11. Section 3, Integrated Semantic Information Model, 2nd paragraph, "The semantic model is realized as an RDF-based knowledge graph..." How this semantic model and the knowledge graph is developed? Is it developed manually or automatically? 12. Section 3.1, Design Decisions and Related Work, 3rd paragraph, "....or information model from scratch, we analyzed existing solutions for suitability." Please provide details of what considerations were given to analyze ontologies? how the suitability of ontologies was assessed? did you have to do any adaptation or changes to the ontologies to meet your requirements? 13. How did you assess the correctness, completeness, and coverage of the information using your knowledge graphs and the model? 4. How generic is the proposed model? Can you reuse the proposed model to formalize information content related to another similar construction building?"".
- Paper.102_Review.2_Reviewer type RoleDuringEvent.
- Paper.102_Review.2_Reviewer label "Anonymous Reviewer for Paper 102".
- Paper.102_Review.2_Reviewer withRole ReviewerRole.
- Paper.102_Review.2_Reviewer withRole AnonymousReviewerRole.
- Paper.102_Review.2 type ReviewVersion.
- Paper.102_Review.2 issued "2001-02-10T08:34:00.000Z".
- Paper.102_Review.2 creator Paper.102_Review.2_Reviewer.
- Paper.102_Review.2 hasRating ReviewRating.1.
- Paper.102_Review.2 hasReviewerConfidence ReviewerConfidence.4.
- Paper.102_Review.2 reviews Paper.102.
- Paper.102_Review.2 issuedAt easychair.org.
- Paper.102_Review.2 issuedFor Conference.
- Paper.102_Review.2 releasedBy Conference.
- 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"".
- Author.106.1 type RoleDuringEvent.
- Author.106.1 label "Julien Romero, 1st Author for Paper 106".
- Author.106.1 withRole PublishingRole.
- Author.106.1 isHeldBy Julien_Romero.