| CreationDate
|
24 August 2012 +
|
| HasClearFigures
|
Clear and understandable, though it would be better to develop the figure vertically a little more.
|
| HasClearProblemDescription
|
Clear, but it seems to tackle two problems, i.e. parametric processes and cause/effect relations. Content Patterns should be atomic solutions whenever possible.
|
| HasClearRelevanceDescription
|
Clear. Thers's one extra newline in the "Consequences" field.
|
| HasMissingInformation
|
- Labels and comments for most entities
- … - Labels and comments for most entities
- There is a scenario annotation in the ontology - It would be good to add a more elaborate version of it to the "Scenarios" section of the pattern page (not just the field in the general description).
- The OntoMDL implementation should be mentioned (with a link to the ontology) in the "Known Uses" field.
- I personally would suggest that Content Patterns start to use OWL 2 version IRI, given that they are subject to refinement -> versioning. Please note that version IRIs should resolve to the specific version of the ontology, while the ontology IRI should resolve to the latest stable release. ould resolve to the latest stable release.
|
| HasProblems
|
- From the competency questions, it is not … - From the competency questions, it is not clear if input, output, conditions and triggers (events) need to be instantiated as actual values, or simply *categories* of parameters, conditions and events.
- Wouldn't it be possible to relax existential restrictions on input/output parameters for the Process class?
- Typo: Property "hasEnvironemntalCondition" should be "hasEnvironmentalCondition" ion" should be "hasEnvironmentalCondition"
|
| HasRelations
|
It would probably be better off specializing some other content pattern, e.g. Reaction.
The "Parameter" pattern could also be specialized.
|
| HasRelevance
|
High, due to its attempt at tackling the cause/effect representation problem and bringing it to the domain of process models.
|
| HasReusability
|
Reusable, with the possible drawback of na … Reusable, with the possible drawback of namespacing. Every entity is defined in-house with namespace "http://purl.org/biomass/ReactorPattern#", which means that if I reuse this pattern, it could remain isolated from other imported definitions of Process, Event, etc. unless I manually align them. The pattern itself should reuse these base concepts. n itself should reuse these base concepts.
|
| HasReviewScore
|
1 -needsminorrevision +
|
| HasReviewSummary
|
The pattern brings a nontrivial modeling p … The pattern brings a nontrivial modeling problem to the domain of process and workflow representation.
If the pattern is revised to reuse existing patterns, provides less in-house namespacing and integrates more entity annotations, it will be a fine addition and a prime candidate for the catalogue. To that end, it would be good to issue a revised version with its own version IRI.
Some rather feasible presentation issues in the pattern page should be addressed as well. pattern page should be addressed as well.
|
| HasReviewerConfidence
|
High (ontologies, OWL, ontology design patterns), Medium (process modeling)
|
| HasUnderstandability
|
The intent and implementation are very clear, sans the issues described in other fields.
|
| IsBestPractice
|
It could set a standard solution for process modeling in various domains, provided that its relation with patterns like Parameter and Reaction is well-defined.
|
| LastModifiedDate
|
24 August 2012 +
|
| Modification dateThis property is a special property in this wiki.
|
24 August 2012 10:27:10 +
|
| ReviewAboutSubmissionThis property is a special property in this wiki.
|
Reactor pattern +
|
| ReviewAboutVersion
|
11,155 +
|
| SubmittedBy
|
AlessandroAdamou +
|
| Categories |
QCReview +
|
