Review Comment:
# A Unified and Evolvable Knowledge Graph Management Mechanism for Medical Data
-- Summary
The work tackles an important issue: managing evolving knowledge graphs and describes an application in the medical domain.
Unfortunately, the paper is missing a problem formalization and the data model formalization is too vague, hence it is not possible to judge wether the proposed solution is in fact appropriate.
Overall, it is also unclear why the proposed solution is specifically targeted or well suited for the medical domain.
Finally, the experimental evaluation is completely missing a comparison to a baseline system.
Therefore, it is unclear whether this solution is practically advancing the state of the art.
Strong points:
S1) important research area
S2) considers end-to-end pipeline
S3) experiments consider real datasets
Weak points:
W1) lack of formalism
W2) limited and ill specified scope
W3) unclear experimental evaluation
Detailed Comments:
D1) The introduction lists 3 research challenges. These challenges are not formalized in corresponding problems later on. The work is missing: a formal model of the data and a formal definition of the problems under study.
D2) Overall, the minimal formalization present is at points incomplete and at other points inconsistent. Definition with equation 1, the contents of sets V_i are not defined, as well as the contents of F, A, R. Also Why is that V_i =SO_i ? why having both? This is confusing. Furthermore, the title and abstract talks about a Knowledge Graph, while in the text sometimes ontology is used, as well as in core parts of the solution. This is a fundamental inconsistency, which invalidates the work at its core.
D3) A running example of the evolution problem should be presented and used across the paper to clarify the presentation. Overall, using examples cannot in any way substitute a detailed formalization of the data model and the problem.
D4) The work seems to only consider subsequent versions of an ontology. On this note than, it appears that the goal is to find between definitions across 2 versions, which definitions map to each other. This is then a subset of the ontology alignment problem. If this is the case, a number of questions are left unanswered:
- Why is this mapping required to be done automatically? A new ontology version is usually generated from the previous one with some edits, thus the ontology editor can simply mark this connections.
- Why no comparison is given with ontology alignment methods?
D5) Figure 1 (B) typo in label "evolvale" . Also "Other cases" is very vague and handwavy. Should be removed or replaced with something concrete
D6) IT is unclear what is the purpose of the unified data structure. The KG or ontology need to be stored within a triplestore in order to enable inference and querying. So what is the role of this in the overall picture of a KG management system? Moreover, ontologies are not very large, why is space efficiency an issue? Moreover, the UDS simply stores all information without any specific or novel idea. It looks like a very naive encoding technique used already in temporal databases with record timestamps. What is supposed to be special about this data structure?
D7) Overall the text uses too many abbreviations which are confusing
D8) No discussion is given of the issues that a wrong detection can cause.
D9) Only one dataset is used. Moreover, the dataset is not characterized. How large is it, how many triples, how many different entities, how much it changes through time?
| 
