http://ontologydesignpatterns.org/index.php?action=history&feed=atom&title=Reviews%3AAlessandroAdamou_about_Reactor_pattern 2026-09-09T13:38:57Z Revision history for this page on the wiki MediaWiki 1.25.6 http://ontologydesignpatterns.org/index.php?title=Reviews:AlessandroAdamou_about_Reactor_pattern&diff=11174&oldid=prev 2012-08-24T10:27:10Z

<p>New page: {{Content OP Proposal Review Template |CreationDate=2012/8/24 |SubmittedBy=AlessandroAdamou |ContentOPUnderReview=Reactor pattern |RevisionID=11155 |Score=1 - needs minor revision |ReviewS...</p> <p><b>New page</b></p><div>{{Content OP Proposal Review Template<br /> |CreationDate=2012/8/24<br /> |SubmittedBy=AlessandroAdamou<br /> |ContentOPUnderReview=Reactor pattern<br /> |RevisionID=11155<br /> |Score=1 - needs minor revision<br /> |ReviewSummary=The pattern brings a nontrivial modeling problem to the domain of process and workflow representation. <br /> <br /> 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.<br /> <br /> Some rather feasible presentation issues in the pattern page should be addressed as well.<br /> |ReviewConfidence=High (ontologies, OWL, ontology design patterns), Medium (process modeling)<br /> |ReviewProblems=- 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.<br /> - Wouldn't it be possible to relax existential restrictions on input/output parameters for the Process class?<br /> - Typo: Property &quot;hasEnvironemntalCondition&quot; should be &quot;hasEnvironmentalCondition&quot;<br /> |ReviewRelevance=High, due to its attempt at tackling the cause/effect representation problem and bringing it to the domain of process models.<br /> |ReviewBestPractice=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.<br /> |ReviewReusability=Reusable, with the possible drawback of namespacing. Every entity is defined in-house with namespace &quot;http://purl.org/biomass/ReactorPattern#&quot;, 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.<br /> |ReviewRelations=It would probably be better off specializing some other content pattern, e.g. Reaction.<br /> <br /> The &quot;Parameter&quot; pattern could also be specialized.<br /> |ReviewUnderstandability=The intent and implementation are very clear, sans the issues described in other fields.<br /> |ReviewClearProblem=Clear, but it seems to tackle two problems, i.e. parametric processes and cause/effect relations. Content Patterns should be atomic solutions whenever possible.<br /> |ReviewClearRelevance=Clear. Thers's one extra newline in the &quot;Consequences&quot; field.<br /> |ReviewFigures=Clear and understandable, though it would be better to develop the figure vertically a little more.<br /> |ReviewMissing=- Labels and comments for most entities<br /> - There is a scenario annotation in the ontology - It would be good to add a more elaborate version of it to the &quot;Scenarios&quot; section of the pattern page (not just the field in the general description).<br /> - The OntoMDL implementation should be mentioned (with a link to the ontology) in the &quot;Known Uses&quot; field.<br /> - I personally would suggest that Content Patterns start to use OWL 2 version IRI, given that they are subject to refinement -&gt; 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.<br /> }}</div>

AlessandroAdamou