Review Comment:
The authors have taken into account all my major comments. I believe that the readability of the paper has been increased significantly. The work presented is quite useful for KG summarisation and exploration and monitoring the evolution of a KG (as done with different wikidata versions). Still there might be some more opportunities for small improvements here and there.
In Figure 1, the threshold Tp and threshold Tdr boxes are meant to indicate (user) input to a processing block hence they shouldn't be in between the actual data processing boxes. It should be something like this:
Tp
'Build subgraphs with | 'return most used
instance of each ---> properties above Tp
selected class' for each subgraph'
The description of the section of relevant classes talks about distances ("if Tc is equal to 0 only the most instantiated class will be considered"), however, in Algorithm 1 the measure used is closeness and not distance, hence (in line 9) if Tc is 0 then all classes are selected and not only the most instantiated. Could you please check?
Algorithm 1:
It is better to use some other letter (e.g., D) for ObjectClasses since R is usually used for relations/properties.
The DL notation in line 16 is not correct. It should be C \and \exists P.R (or if take the previous comment into consideration it should be C \and \exists P.D)
'For instance, you can create a ShEx shape stating that an instance of a book must have...'. It would be good to actually provide the ShEx shape.
'However, unlike OWL property restrictions on classes, they do not limit the applicable classes'. Since OWL has open-word semantics, I am not sure we can claim that OWL domain/range restrictions necessarily restrict the classes to be used (unless also combined with some disjointness axioms). Maybe this sentence needs to be revised or dropped.
Properties for this type: 'the appropriate range(s) to be paired with that specific type () cannot be specified'. I think the word 'cannot' is a bit too strong. Couldn't they be specified somehow, but perhaps Wikidata is not providing the mechanism to do so?
I appreciate the authors adding Figure 3 for type of wikidata property. Still however, from an intuitive point of view, I am not getting the idea behind Wikidata type of properties and how this is different from domain/ranges. It is stated that the property 'facet of' connects the metaclass and its topic but then in the given example chessgames.com player ID is a property. So are we talking about (meta)classes or properties. Clearly this is a Wikidata thing and not the authors, but it would be good to understand since it is used in the paper.
'activity in progress'. I feel it is better to call it 'work in progress'
Page 11: The axioms in 1 -> The axioms in Listing 1
Page 15: As in figure 7, IDs properties -> ID properties (no prular on ID ?)
| 
