| CreationDate
|
10 September 2009 +
|
| HasClearFigures
|
Perhaps a single diagram for depicting the … 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. d how they would be related to each other.
|
| HasClearProblemDescription
|
Again, a real-world example should be incl … 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. id, the abstract example is fine as it is.
|
| HasClearRelevanceDescription
|
Perhaps ontology developers should be help … 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. d from using different methods, is needed.
|
| HasMissingInformation
|
Nothing that hasn't been mentioned already … 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<br />
- A reference to an example ontology in English (or at least with English RDFS annotations)<br />
- 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. differences, that should be made explicit.
|
| HasProblems
|
Mostly to deal with pattern presentations. Please see below and also see my review for Disjointness of Complement (DOC).
|
| HasRelevance
|
One thorny issue has come to my mind while … 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. again, other colleagues' mileage may vary.
|
| HasReusability
|
Could apply to a myriad of everyday modelling problems, indeed.
|
| HasReviewScore
|
1 -needsminorrevision +
|
| HasReviewSummary
|
The submission needs to be detailed in sev … 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. d be a task for humans or software agents.
|
| HasReviewerConfidence
|
ODPs: medium/high<br />
Description Logics: medium
|
| HasUnderstandability
|
While the motivation, aim etc. should be q … 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. p. This holds for the DOC pattern as well.
|
| LastModifiedDate
|
10 September 2009 +
|
| Modification dateThis property is a special property in this wiki.
|
10 September 2009 11:30:53 +
|
| ReviewAboutSubmissionThis property is a special property in this wiki.
|
OnlynessIsLoneliness (OIL) +
|
| ReviewAboutVersion
|
5,777 +
|
| SubmittedBy
|
AlessandroAdamou +
|
| Categories |
QCReview +
|
