Typed properties and negative typed properties: dealing with type observations and negative statements in the CIDOC CRM

The authors much improved the quality and clarity of the paper and addressed the issue regarding the discussion about existing alternative solutions.
I still have some doubts about what kind of evaluation is proposed. The evaluation seems to be a dataset accompanied by a set of queries, but it is still not clear its rationale.

The authors have rewritten the article almost entirely, and all the concerns raised in the previous review seem now solved. However, the result is quite difficult to read, and the structure is sometimes confusing.
Specifically, Section 1 should be split from 1.2 onwards into a separate section(s?) dedicated to the problem formalisation and the discussion of related work. It is not a big problem that related work mixes with the problem description. However, sections and subsections should include more connecting sentences to help the reader follow the argumentation.

The lack of a clear place for related work can be confusing; maybe there can be a table summarising the options, with explicit nicknames (e.g. owl-plain-disjoint-classes, disjoint-classes with expressions, disjoint classes with cardinality, etc….)

The evaluation focuses on: (a) how the two solutions (OWL- and RDFS-compatible) can be applied; and (b) how both are solving the problem from the point of view of developing SPARQL queries to answer the questions. The evaluation does not essentially compare to alternative solutions. However, the evaluation framework should be presented and discussed before applying it. It should also be clarified why this approach to the evaluation was considered (how it relates to ontology engineering methodologies, for example).

The overall presentation requires further improvements, for example, formatting the code differently (e.g. using background colours, smaller text, etc.). Sometimes the pages are overcrowded with code snippets, which makes it harder to follow the content. This also applies to Tables.

Evaluating the usability of ontology engineering solutions is tricky, I can recommend the following paper on the topic:

Warren, Paul, Paul Mulholland, Trevor Collins, and Enrico Motta. "The usability of description logics." In European Semantic Web Conference, pp. 550-564. Springer, Cham, 2014.

With this second version the nature of the paper has changed. The focus moved from the discussion of a general problem about knowledge representation to a formal solution relatively to specific application languages (OWL 2 and RDFS). Conceptually speaking, the first version had a more suitable structure since the problem was properly introduced and discussed. This version of the paper is perhaps more relevant to SWJ and definitely useful to the community but the generality of the discussion is lost. To mitigate this, I would suggest to properly isolate some material of general interest like the discussion at pg. 10 (where I suggest to add a distinction btw beliefs, e.g. existence stated by other sources, and existential dependencies, e.g. the presence of glue indicates the earlier presence of leafmarks) but leave the choice to the authors.
I won’t object publication in the current version.

Minor issues:
Pg 2:
- Instead of just P (which is generic) use some characterising decoration e.g. \hat{P}
- “Section 3 evaluates the recommendations by presents an implementation” [presenting?]

Pg 4: “Which individuals are not connected to an individual through P?[“] - i.e., closing quotes are missing

Pg. 11: “such that [it] allows such reasoning.”

Pg. 13: pageMarker1 should be leafMarker1

Q^r (used in Table 2 and later) is not introduced