Reviews:VojtechSvatek about Classification scheme - adjacency list model - to Taxonomy

Revision as of 19:44, 8 September 2009 by VojtechSvatek (Talk | contribs)

(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

VojtechSvatek about Classification scheme - adjacency list model - to Taxonomy (Revision ID: scheme - adjacency list model - to Taxonomy?oldid=5681 5681)

Overall suggestion (score): 0 - needs major revision

Review Summary: A reengineering pattern for a predefined type of tabular structure. Semantic aspects are not taken into account. There are some inconsistencies in the description. However, it is a good starting point for discussion at WOP. I assume it should be explained in the context of reengineering patterns in general.

Reviewer Confidence: The problem is relatively transparent and the domain is generic, so I have high confidence in my assessment.

Problems: 1) Although the semantics of the hierarchical relation 'may vary depending of the context', there are no alternative modelling options offered; the subclass construct is uniformly used, which has the subset semantics; this may lead to discrepancies if the original resource is e.g. partonomy-oriented. This should at least be commented on, as a limitation of the pattern usage.

2) While the problem description assumes that the original source is structured as tree, the process description has a special provision for non-tree structures. This is confusing.

3) When a new 'ad hoc' class is created, it is not clear if it is to be identified with a standard class such as owl:Thing, or given the URI through some naming convention - I would expect such a convention as natural part of the pattern.

Text-level issues: - what is caparentID?

- the last diagram (at example level) is trivial and could safely be omitted

Community Relevance: This kind of patterns is naturally important, as reengineering of non-ontological resources is an ubiquitous problem.

Relation to Best Practices: The problem is simplified such that the current pattern looks like the only straightforward solution. In reality a more complex solution would be needed.

Reusability: The pattern is specific to a particular category of non-ontological resources. However, its abstract part could be reused for some other categories.

Relations to Other Patterns: Obviously, the same non-ontological resources could be transformed to a different ontological form (such as instance-level), presumably using an alternative reengineering pattern.

Overall Understandability: Understandable, even a bit too verbose in places.

Clear Problem Description: As mentioned, the problem is oversimplified. The description of the simple problem, i.e. mechanically transforming a table into an ontology, is clear.

Clear Relevance and Consequences: Not much.

Clear Figures and Illustrations: Clear, and a bit trivial.

Missing Information: