Venue: AIS-J 2021 Journal

Reviews:

final_score: rating: 2: Conditional acceptance
review_content: overview: The paper focuses on the methodology of IFC schema mapping to relational database tables. The authors defined the table design method patterns and evaluated the IFC data query performance with the proposed table patterns. As comprehensive evaluation of the proposed table design methods, it would be better to include the more detailed performance test of IFC data import and the completeness of the IFC schema representation on the proposed methods.
review: - Section 1 Background covers the necessity of BIM data service by touching on the latest 3D city model use cases. The author also states that the difficulties to realize the BIM data service as wide range of data, and complexities of discipline BIM data handling process and specifications. It can be valid statement, and would have been better if the role of IDM(Information Delivery Manual) and MVD(Model View Definition) are mentioned here to describe the BIM process and BIM data specifications.
- Section 2 Research objectives: The term of “original BIM data” is more commonly used as “native BIM data”.
- Section 3 Literature review covers comprehensive previous studies on BIM data model, especially EXPRESS language, mapping to different kinds of database systems.
- Section 4 Research Methodology: In this section, the authors direct the use of RDB to store IFC data into IFC server. It is better that further discussion of comparison between RDB approach and other database systems, such as key-value, big table, and so on.
- Section 5 The structure of the IFC schema: This section seems to be the description of structure of EXPRESS language. It would be better that overview of IFC class hierarchy is mentioned here, so that the mapping rules described in the next section 6 will become much clearer. 
- Section 6 Different types of mapping rules: This section is a main body to describe the IFC schema to relational database (RDB) table mapping methodology. The authors state the table design method in the first half of the section, however the relation between the method pattens and mark number P! to P4 in the figure 1 is ambiguous. And the term of “DBing” should be replaced to a more general term.
- Section 7 About the tool to auto-convert IFC to RDB: It is better to specify the version of IFC4 schema, because IFC4 contains multiple releases at the moment. The part of discussion about the figure 3 of UML of IFC schema parser can be included in the Section 6.
- Section 8 Experiment: The sentence, “benchmark tests were conducted on various DBs” could be misinterpreted as tests were conducted on different DB systems. In my understanding, multiple mapping rules were tested and compared.
- Section 8 Discussion should be 9 in numerical order, and Concluding remarks. 
The completeness of IFC schema representation of the mapped tables should be evaluated and discussed in the future. 
In recent years, commercial IFC model server services have been spreading, and have been used in the development of cloud-based BIM applications in design, construction, and maintenance phases. The buildingSMART International has been working on standardizing the common API specification for IFC model server, named openCDE API, and it is expected that the findings from this paper will contribute to such buildingSMART efforts.

Additional comments:
- Building Information Modeling, BIM, BIM data, and BIM model:
The abbreviation BIM is usually known as Building Information Modeling to imply the process using digital representation in the built environment. On the other hand, the term of data of BIM itself appears BIM model or BIM data, and sometimes BIM as Building Information Model.
The quotation of the building information modeling’s definition from ISO 19650-1: use of a shared digital representation of a built asset to facilitate design, construction and operation processes to form a reliable basis for decisions.

- References [7], the following citation can be better reference:
Y. Adachi, Overview of IFC Model Server Framework, European Conference of Product and Process Modeling ECPPM 2002
review_title: null

final_score: rating: 3: Conditional rejection
review_content: overview: The paper must conclude to resolve the defined problem, not to provide something good to have. The substance must be clarified against the existing literature. The development and evaluation process needs to be thoroughly elaborated.
review: ## Related to the paper

- Overall: While it is stated in Section 2 that the authors “develop a method for building a BIM server,” the contribution could be somewhat identified in the automated process to convert IFC schema to SQL statement; which is only a part of configuring the BIM server for a specific purpose. The paper fails to introduce the research to identify why this technique is worth developing in the broader context. Since the article is titled “The study of BIM server focusing on IFC to RDB conversion,” the following questions should be answered: why does the conversion matter? What is the purpose of such conversion and what is the scope (and limitation)? What are the expected use cases and why are they important?
- Background: In Section 1, the authors state “this study proposes that BIM data should not be contained in a 3D urban model as a mere information source, but should aim to become a data services provider,” which is literally inconsistent with the original purpose of using BIM. Despite some examples being drawn, the authors should refer to more existing publications to reinforce the argument.
- Research Objectives: In addition to the above, what are the expected contributions? What is more than “just good to have?”
- Literature Review: The mentioned literature is biased and unexhaustive. There exist tens of academic publications regarding IFC conversion, for example, *Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings* (Donkers et al, 2016) or *An evaluation of IFC-CityGML unidirectional conversion* (El-Mekawy et al, 2012), as long as I searched. The authors must introduce the relevant existing research, allocate their argument to them, and prove that the parallel efforts are made compared to the reference.
- Research Methodology: The current statements have little to do with the actual methodology. If the significance lies in the converter and the evaluation process, it must be detailed in the section. It is slightly mentioned in Section 7, but this should be fully described in the earlier part. It also should be considered to implement the existing research framework to reorganize the paper.
- Research Core: Sections 5 and 6 are unnecessary. The authors should focus on the necessary concept by using the reference and elaborate more on what actually they developed/analyzed. The meaning of provided figures is very vague; the authors should thoroughly revise the figures to address the original contribution of the paper.
- Section 7 seems to be the core of the paper, however, the authors do not clearly identify the problem and elaborate on the efforts they made. Some technical challenges are highlighted, but the fundamental question then comes back to: “what is better than the existing ones, and why do we need it.” The paper should be streamlined to explain why that is the missing piece to solve the problem in line with the broader context.
- Section 8 only has a poor description of what was done. What are the details of the data? Why are these different types deployed? Where is the reference for BUCKY Benchmark, what is it, and why is it adopted? What was the purpose to test these three data sets?  Overall, what can be scientifically concluded from the benchmark test and what is the implication (to be addressed in the Discussion section)?
- Discussion and Conclusion: The conclusion is not clear and conclusive. The current sections only say that the authors created an automatic IFC conversion tool that sounds potentially useful in building RDB. What are the significances compared to the existing approach? What was technically overcome, that has not been resolved in the existing efforts? What are the limitations? And most importantly, how do you answer the question you formed in the introduction?

## Some additional comments:

- Please write the full form of the acronym for the first time, like RDB.
- Please revise the Japanese abstract.
review_title: null