Review Summary: The submission needs to be detailed in several respects. The pattern proposal itself makes pretty much sense, but end-users should be guided a little more in deciding if and where to apply it. To stretch this aspect to its extremes, WOP could be a suitable place for discussing if applying such a pattern should be a task for humans or software agents.
Reviewer Confidence: ODPs: medium/high
Description Logics: medium
Problems: Mostly to deal with pattern presentations. Please see below and also see my review for Disjointness of Complement (DOC).
Community Relevance: One thorny issue has come to my mind while reviewing this proposal, and I believe it could raise a relevant point of discussion.
The authors argue that there are psychological motivations for following this antipattern, as modellers tend to forget about having previously added certain restrictions to their ontology. For that matter, they might not even remember that they should apply this pattern, though.
So, I think it should not be their job to apply this pattern manually, and the task could be deferred to automatic refactoring engines in development tools, APIs and so on. If using the pattern or the antipattern may not be considered to be semantically equivalent human intervention could be requested on a case-by-case basis.
But then again, other colleagues' mileage may vary.
Relation to Best Practices:
Reusability: Could apply to a myriad of everyday modelling problems, indeed.
Relations to Other Patterns:
Overall Understandability: While the motivation, aim etc. should be quite clear to the seasoned knowledge engineer (who is less likely to incur in antipatterns, though), maybe the narrative should be thought of from the angle of the less experienced.
The name of this proposal is very poetic and that's appreciated, but this can a double-edged sword. As an ontology engineer in training, it would never come to my mind that I could make use of this pattern in my everyday modelling activities. Also, we have an OIL acronym in the discipline of Web Ontologies since 2001, and I think such clashes should be avoided at least in the same research field.
The motivation is clear enough, though maybe it should be a little more targeted at the naive ontology developer coming to the ODP portal to seek help. This holds for the DOC pattern as well.
Clear Problem Description: Again, a real-world example should be included directly in the pattern description, and not entirely deferred to the example ontology (which, by the way, non-Spanish speakers may have some trouble interpreting). With that said, the abstract example is fine as it is.
Clear Relevance and Consequences: Perhaps ontology developers should be helped a little more in finding out when this patterns applies to their case. The authors suggest to replace two or more anonymous classes with a single one "if it makes sense", but not everyone might have a clue as to when it makes sense and when it doesn't. If the statements can be considered equivalent (which is my impression), then this should be made clear, otherwise an example, describing how different facts can be inferred from using different methods, is needed.
Clear Figures and Illustrations: Perhaps a single diagram for depicting the scenario could be helpful. Since the authors claim the pattern to be only a rewording on a certain type of statement, it is not possible to show how using the pattern or the antipattern would yield different results. However, an illustration could at least show an example of what we are trying to model, including instances and how they would be related to each other.
Missing Information: Nothing that hasn't been mentioned already. To sum it up:
- A concrete example right in the pattern description, possibly accompanied with its ontology diagram
- A reference to an example ontology in English (or at least with English RDFS annotations)
- A clear statement on the consequences of adopting the pattern rather than the antipattern, if any. If there are no differences, that should be made explicit.
