Definition of classes (lexical) |
5 |
The reviewers agreed that the lexical definition of each class is clear |
Hierarchical structure (sub-classes hierarchy) |
4 |
The reviewers agreed that the sub-class hierarchy faithfully represents the CEM specifications. There is a concern about defining the basic category classes (eg, SimpleStatement and ComponentStatement) and the specialized classes (eg, Patient, Activity, etc) as sibling classes under the Statement class since they represent different types of classifications of CEMs. An alternative solution could be to create two parent classes under the Statement class to separate the two groups of classes |
Definition of classes (semantic) |
5 |
The reviewers agreed that the semantic definition of each class is correct |
Semantic relations (object property definitions) |
5 |
The reviewers agreed that the domain and range defined for each property are correct |
Context and application (validation of the usage of the CEM-OWL model in a detailed CEM)
|
Class usage |
4 |
The reviewers agreed that defining each detailed CEM (eg, BloodPressurePanel) as a new class and a subclass of the category it belongs to (eg, Panel) is appropriate and semantically correct. There was a discussion about the option on defining each detailed CEM as an individual of the category class (eg, BloodPressurePanel rdf:type Panel). The reviewers agreed that the current way is more appropriately aligned to the three-layer approach used for this representation |
Relation usage |
5 |
The reviewers agreed that the relations defined in the meta-ontology are sufficient to represent the connection between components in the detailed CEM |
Cardinality constraints |
5 |
The reviewers agreed that the cardinality constraints are defined correctly and the OWL cardinality constraints are sufficient to represent CEM cardinality constraints |