Property:HasReviewSummary
From Odp
This is a property of type Text.
(previous 25) (next 25)
Pages using the property "HasReviewSummary"
Showing 25 pages using this property.
B | |
|---|---|
| BorisVillazón-Terrazas about Template Instance + | This pattern describes how to reify a reoc … This pattern describes how to reify a reoccurring set of instances in a given ontology. The pattern allows to minimize the number of times that the reoccurring instances need to be instantiated in the ontology model by creating the notion of an "instance template". ting the notion of an "instance template". |
| BorisVillazón-Terrazas about TransportPattern + | The author claims that the goal of the pat … The author claims that the goal of the pattern is to facilitate modelling the movement of mass or energy from one location to another, based on a common persistent frame of reference. However, I'm not sure if the property transportEvent fully covers the aspect of the movement mass. The authors should clarify and improve the description of this. arify and improve the description of this. |
| BorisVillazón-Terrazas about Xsd:sequence embedding + | I think a reengineering pattern for partOf … I think a reengineering pattern for partOf relation in XML-based documents is more general than the XSD case presented. So, the XSD case would be an example of the pattern. Also, the output is just an excerpt of an ontology. The pattern is suitable for presentation at WOP, but after a major revision. ation at WOP, but after a major revision. |
C | |
| CatherineRoussey about ExperimentalParadigmData + | The ODP presents the role of entities in e … The ODP presents the role of entities in experiment study. This ODP is linked to the SOSA ODP (in the sosa ontology) and the I-adopt ODP (in the RDA I ADOPT data model about variable description). The role of entity should be presented as subClass of Entity class. a variable is a kind of observable property of the entity that play the role of experimental subject. The link between the instrument and each observable property is not specified, neither the link between the instrument and the output. It is not possible to find for each output what is the observable property and the acquisition instrument. The experiment has several type of outputs, that could be a single measure ( like SOSA observation) or a file with a set of measurements or another type of files that need extra analyse to identify the observable property of the entity ( a video that should be analysed). Metadata is ambiguous and should be clarified: authors ( an agent role of the experiment) uthors ( an agent role of the experiment) |
| CatherineRoussey about Inverse n-ary relationship + | This pattern express that an n-ary relatio … This pattern express that an n-ary relationship (OffersServiceAtPlaceTimeWithPrice) can be summarize in a simple relationship (provideService property) between the two main participants (ServiceProvider and Service). The relationship between the two main participants can be modelized with different details (rought modelization and detailed one). The purpose of this pattern is to make the querying of the knowledge based more easy. But you will have to manage the updating of the knowledge base. The simple relation may exist even if the n-ary relationship do not...and vice versa...So if there is no problem with that point I am OK... Maybe you could explain that the creation of the simple relationship can be derived from the existence of the n-ary relationship. m the existence of the n-ary relationship. |
| CatherineRoussey about LinnaeanTaxonomy + | in taxonomy domain, the number of rank is … in taxonomy domain, the number of rank is not fixed. A taxonomy should contain at least the rank : species, genus, family, order, class, gender, phylum, kingdom. These rank are called major rank. But more rank can be specified like subspecies, super family, variety etc... see the wikipedia page for more information http://en.wikipedia.org/wiki/Taxonomic_rank Thus the universal restriction constraints should be removed to be used by any kind of taxonomy. The constraint that fix the direct parent rank in the taxonomy can not be specified in this pattern. nomy can not be specified in this pattern. |
| CatherineRoussey about Normalization + | This pattern is very usefull when you want … This pattern is very usefull when you want to validate a classification and make some modifications. In the cell ontology, I have downloaded from the ODP portal, there is no disjointness relationships. But in the description on the modularization process, the author mentions "making primitive siblings disjoint". Thus, it is not easy to understand which the disjoint siblings are ... Could you modify the example and add disjointness relationships. Moreover what happens when the ontology is too big to allow a reasoner to infere the new classification ... Maybe a scenario may be proposed in order to explain how to validate part of a huge classification... To my point of view the infered subClassOf relationship may be saved for manual research... You can image to save two versions of the same classification, the one to validate the classification (this one can be used for modification) and another one that save a version of the classification in a validate state. This version will be usefull for manual research without reasoner. full for manual research without reasoner. |
| CatherineRoussey about SimpleOrAggregated + | I do not understand exactly what will be t … I do not understand exactly what will be the purpose of this pattern and Which behavior the author expect from the reasoner. So I need more information to give a review. The main problem is the semantic of the aggregation property. There exist different partOf relationship and I need to know the relationship between the aggregation property and the partOf one... aggregation property and the partOf one... |
E | |
| EnricoDaga about Xsd:sequence embedding + | This submission needs major revision. It i … This submission needs major revision. It is not clear if the aim is to model a partitive relation between embedded xml elements to the relative parent element in general or in particular for the xsd:sequence element. In the second case the partOf property defined in DOLCE is not enough, better use the [[Submission:Sequence]] pattern. In the first case the pattern should be focused on the xsd:all element instead. Additionally, a reengineering pattern for partitive relation in XML-based documents is more general then the XSD case, and probably should be approached at that level, focusing on XSD case in the example section. cusing on XSD case in the example section. |
| EnricoMotta about Context Slices + | This is a very interesting and useful patt … This is a very interesting and useful pattern providing a generic solution to a modelling problem which is more or less ubiquitous when using KR techniques to solve real world problems. However, the description of the pattern (in particular, motivation and pros and cons of the solution) is a bit unclear in parts and ought to be improved, esp. to clarify the pros and cons of the solution to users who may have enough knowledge to apply the pattern to a modelling problem but are not necessarily familiar with all the finer points of meta-level KR. ith all the finer points of meta-level KR. |
| EnricoMotta about Literal Reification + | Useful pattern supporting the reification … Useful pattern supporting the reification of literal values within OWL, so that they can be used as 'first class objects' in OWL models. The pattern seems valid, however I had trouble trying to browse it in both NeOn and Topbraid, which made my life a bit painful. I am also surprised that the pattern does not clarify how to link the resulting reified literals to the obvious related entities - e,g, an entity such as http://dbpedia.org/resource/Hilton%2C_Paris, which describes ParisHilton. ton%2C_Paris, which describes ParisHilton. |
| EvaBlomqvist about CommunicationEvent + | Some things can be improved |
F | |
| FrancoisScharffe about Classification scheme - adjacency list model - to Taxonomy + | This pattern present the process of transf … This pattern present the process of transforming an adjacency list into an owl class hierarchy. The problem is simple, well described and well illustrated. My only concern is that the relation between the termis in the adjacency list might not correspond to a subclass relation. In this case the pattern shouldn't be used. This should be explicitely mentioned. sed. This should be explicitely mentioned. |
| FrancoisScharffe about ConceptGroup + | This pattern is meant to be used to repres … This pattern is meant to be used to represent group memberships of concepts. Sub and super groups can be represented, and both extensional (declared) and intensional (according to a property) memberships can be modeled. The pattern seems interesting but present many shadowed areas. I can deduce from the usage of the terms concept ans broader/narrower relations that this pattern is to be used together with the SKOS vocabulary. If this is the case this should be made explicit. Otherwise, what is the relation of this pattern with owl ? I lack an example instantiation of the pattern. The Solution Description contains questions ... Questions are no solutions... In summary I think it is an interesting pattern which could certainly find applications when publishing terminologies with SKOS. The pattern however needs to be better described. This pattern can definitely lead to interesting discussions. efinitely lead to interesting discussions. |
| FrancoisScharffe about ConceptGroup + | This pattern is meant to be used to repres … This pattern is meant to be used to represent group memberships of concepts. Sub and super groups can be represented, and both extensional (declared) and intensional (according to a property) memberships can be modeled. The pattern seems interesting but present many shadowed areas. I can deduce from the usage of the terms concept ans broader/narrower relations that this pattern is to be used together with the SKOS vocabulary. If this is the case this should be made explicit. Otherwise, what is a concept wrt an owl:Class ? I lack an example instantiation of the pattern. The Solution Description contains questions ... Questions are no solutions... In summary I think it is an interesting pattern which could certainly find applications when publishing terminologies with SKOS. The pattern however needs to be better described. This pattern can definitely lead to interesting discussions. efinitely lead to interesting discussions. |
| FrancoisScharffe about Enlarge Class Definition for Resolving Disjointness due to Subsomption + | This pattern suggests solution for solving inconsistency problem caused by subsumption of two disjoint classes by enlarging class definition. |
G | |
| GerdGroener about Classification scheme - path enumeration model - to Taxonomy + | This pattern describes a taxonomy creation … This pattern describes a taxonomy creation from a classification scheme based on a path enumeration model. The idea is to represent the parent and children relation from the classification scheme which is a rooted tree by subClass relations between concepts in the taxonomy. This kind of representation and transformation is straightforward and simple, but the pattern is quite complex. The proposed pattern could be interesting for discussions at WOP since schema re-engineering is common modelling problem. However, the pattern as it is proposed is rather complex for a very simple and basic modelling guideline (classified tree entities represented in a taxonomy). Therefore the quality and relevance of this pattern is not very high. elevance of this pattern is not very high. |
| GerdGroener about DisjointnessOfComplement (DOC) + | The motivation of the pattern is very good … The motivation of the pattern is very good and in fact the misunderstanding of DL expressions leads to modeling errors and ambiguity. However, I'm not sure whether this pattern is very helpful. With respect to the described "Aim" in the pattern, I don't understand why a developer defines C1 as the logical negation of C2 instead of (probably more intuitive) using a disjointness axiom. This could be a very interesting pattern/topic for discussion at WOP, for instance what is the intention of using disjointness instead of negation (are there benefits)? However, the submitted pattern proposal so far is to weak to be accepted as a pattern. At least more explanation is necessary. n. At least more explanation is necessary. |
| GerdGroener about Inverse n-ary relationship + | The pattern extends (or restricts) the n-a … The pattern extends (or restricts) the n-ary relationship pattern (Pattern1) from W3C. In the W3C pattern, the elements of the n-ary relation are non-distinguished. In this case, the inverse property means defining the inverse property of all properties. The proposed pattern makes a simple, but from my point of view a quite restricting assumption. In the n-ary relation, there are two distinguishable elements and the ontology engineer is only interested of the inverse property of the property that connects this two elements. The other elements are considered as optional. Concerning this restriction, I doubt that this is really a n-ary relation! The focus is only on the relations between this two distinguishable elements. The others can be neglected. ble elements. The others can be neglected. |
| GerdGroener about SimpleOrAggregated + | The pattern describes a disjoint partition of objects into simple and aggregated objects that consist of at least two objects. The proposed solution seems to be sound. There is just one minor remark (see problems). |
| GerdGroener about Standard Enforcer Pattern + | Pattern Summary The proposed pattern desc … Pattern Summary The proposed pattern describes modelling guidelines to describe a standard and the process that enforce the standard. Evaluation of the Pattern The pattern is useful and the example helps to understand the pattern. I would suggest to elaborate the ontological presentation of the patter, i.e., explain in more detail the modelling principles (in OWL) of the pattern as depicted in Fig. 1. Furthermore, Fig. 1 is not readable as some text is missing (not completely displayed). Thus, for the final submission, both the Figure and the explanation of the OWL-modelling principles have to be improved/added. ling principles have to be improved/added. |
| GerdGroener about SynonymOrEquivalence (SOE) + | The proposed pattern (or anti-pattern) is … The proposed pattern (or anti-pattern) is useful for ontology engineering, especially for less experienced developers. It focuses a common modeling problem. The proposed anti-pattern is technical sound. However, it is quite simple. Due to the simplicity of the pattern there are few discussion issues at WOP. rn there are few discussion issues at WOP. |
H | |
| HenrikEriksson about Partition + | This is definitely a pattern that should be every ontology engineer's toolbox. However, the current description is poor. The wording in the motivation and aim should be improved and examples added. |
I | |
| IonelVirgilPop about Reactor pattern + | Review Summary: The main reason I propose … Review Summary: The main reason I propose to reject this pattern is that it appears to be, just like the so called "Standard(s) Enforcer Pattern", an attempt to generalize my "OOPMetrics" content pattern, but without citing the source. Reviewer Confidence: High (afterall, it looks like a generalization of my own pattern). Problems: The main reason I propose to reject this pattern is that it appears to be, just like the so called "Standard Enforcer Pattern", an attempt to generalize my "OOPMetrics" content pattern, but without citing the source. Even if this is a collaborative website, I believe the source should still be cited, if it was based on it. There would have been ways of citing the source such as put a link to the OOPMetrics ontology pattern in the section "Web References" and in "Related CPs". The Reactor Pattern was submitted after the OOPMetrics (this can be checked on this website). Here are just a few reasons (there are others) why I believe it is a variant (generalization) of OOPMetrics: - it uses metrics in the same manner as OOPMetrics, of course here we have hasMeasure instead of hasOOPMetric. - in the scenario, instead of the metrics used for OOP, in this pattern there are some metrics regarding carbon, total energy, etc. They are used to detect things like waste output in the same manner I used OOPMetrics to detect design-flaws. - I believe that the so called OntoMDL ontology doesn't even exist. It's just an excuse to create a scenario much like the God Class scenario I presented in the article and described on this website. If the author would have understood her own ontology pattern she should have been able to create this OntoMDL ontology and put a link under examples. It would have been something more that what OOPMetrics already has. But, of course, since OOPMetrics doesn't have an ontology example neither does this pattern. - The wrong text: words without spaces among them, the property "hasEnvironemntalCondition" that should be "hasEnvironmentalCondition" as another reviewer observed, show that this was done in a rush. - lack of labels, like in the first version of OOPMetrics. Moreover, both the "Reactor Pattern" and the "Standard Enforcer Pattern" were submitted AFTER THE DEADLINE, while the "OOPMetrics" was submitted just before the deadline. It can be clearly seen, if someone clicks on "history" on top of the pattern page, that the first submission was on August 13, and the extended deadline was august 10. I understand that the time format on this website may not be the Hawaii time like in the call, but still there are three days between the two dates. Of course, the author could not have submitted the pattern before, if it was based on my pattern, because I submitted my own pattern just a few hours before the deadline. Now I am glad I submitted my pattern just a few hours before the deadline. And I believe the article that should have been submitted on easychair, if one was submitted by this author as stated in the call, could not have possibly be submitted before the deadline either, unless one of the organizers/evaluators facilitated a further extension of the deadline for this author. I hope this author didn't had access to the article I send on easychair as well, since normally the article is not public and should not be published until/if accepted. And normally only organizers/evaluators should have access to it. Community Relevance: None (I don't see why we need two generalizations of OOPMetrics, such as both the "Reactor Pattern" and the "Standard Enforcer Pattern", other then to look different and to have more chances of acceptance of at least one of them). Relation to Best Practices: None (this pattern does not look like it was based on best practices of creating ontologies, it looks like it was made in 10 minutes based on OOPMetrics, without citing the source). Reusability: It has worse reusability than OOPMetrics, and this was attempted to be more general. It was attempted to appear more complicated by adding equivalencies and comments, instead of "real content". Relations to Other Patterns: I believe it has a relation with the "Standard Enforcer Pattern" and with my "OOPMetrics", in the sense that Reactor Pattern + Standard Enforcer Pattern = a generalization of OOPMetrics. Overall Understandability: A generalization of OOPMetrics would be useful, but I don't understand why this particular pattern would be useful and I can't understand why we need to have two generalizations: Standard Enforcer and Reactor Pattern. Clear Problem Description: Bad Clear Relevance and Consequences: Bad Clear Figures and Illustrations: I don't see why there is rdfs:subClassOf in the diagram so many times instead of the "inheritance" relation. It's too much text in the diagram. Missing Information: citations are missing in this pattern description. This website may be collaborative, but I still believe citations are required if it was based on another pattern, otherwise one could do even more strange things, like simply copy an existing pattern and just change the name of the author. And perhaps the citation is missing in the article that should have come with this pattern as well. Also, the domain is not stated, perhaps it's "general". I gave a similar review to the "Standard Enforcer Pattern". I'm sorry if I repeated myself, but some "mistakes" seem to be common. I am proud that one reviewer had such an appreciation of this pattern, afterall it is a generalization of my own pattern, but I still believe it is a bad generalization. I would recommend other reviewers to take note of my review and compare these three patterns, or they may get in the trap of following the principle: "Let's reject the original, so we can accept the "copy" ". e original, so we can accept the "copy" ". |
| IonelVirgilPop about Standard Enforcer Pattern + | Review Summary: The main reason I propose … Review Summary: The main reason I propose to reject this pattern is that it appears to be, just like the so called "Reactor Pattern", an attempt to generalize my "OOPMetrics" content pattern, but without citing the source. Reviewer Confidence: High (afterall, it looks like a generalization of my own pattern). Problems: The main reason I propose to reject this pattern is that it appears to be, just like the so called "Reactor Pattern", an attempt to generalize my "OOPMetrics" content pattern, but without citing the source. Even if this is a collaborative website, I believe the source should still be cited, if it was based on it. There would have been ways of citing the source: put a link to the OOPMetrics ontology in the section "Web References" and in "Related CPs". The Standard Enforcer Pattern was submitted after the OOPMetrics (this can be checked on this website). After some time, the "Standard Enforcer Pattern" appeared, which looks like a generalization of it. Even some phrases look similar to me. Here are just a few reasons (there are others) why I believe it is a variant (generalization) of OOPMetrics: -in my ontology pattern (OOPMetrics ontology pattern) one of the competency questions is: "What are the software metrics for a particular project/package/class/method?" -in the "Standard Enforcer Pattern" the description of the ProcessEnforcingStandard is: "A process/operation/activity or serrvice that enforces one or more standard." (looks like a generalization) -the intent is also similar, although explained differently and for a general domain. -the ontology is not very complex, but it was made to appear that way by putting a lot of equivalences, textual descriptions/comments, but little "real content". It seems that the "real content" and the idea is mostly "borrowed" from OOPMetrics. It looks like it was done in 10 min based on OOPMetrics, but for a general domain and without citing the source. -in the scenario there are mentioned a "set of descriptive metrics", but there is no class about metrics in this pattern and it is unclear how this pattern can actually be of use in this scenario. It looks somewhat like my God Class scenario, but this is for "algal biomass production". Here the so called "guidelines" are similar to the rules needed to see if a class is a God Class, based on it's metrics. Again, it looks like it was created in 10 min, based on OOPMetrics, without citing the source. -labels are missing, just like in the first version of OOPMetrics. Community Relevance: Bad (a generalization of OOPMetrics could be useful, but I don't believe this particular pattern is a useful generalization, and does not cite the source). Relation to Best Practices: I don't believe it was based on best practices of writing ontologies over the years, it looks like it was done in 10 min based on OOPMetrics. Reusability: Bad (it was perhaps intended as a generalization, but it has some additional classes that are not necessary and I don't think it's very reusable) Relations to Other Patterns: I believe it has a relation with the "Reactor Pattern" and with my "OOPMetrics", in the sense that Reactor Pattern + Standard Enforcer Pattern = a generalization of OOPMetrics. Unfortunately, neither one is mentioned as a Related CP. Overall Understandability: A generalization of OOPMetrics would be useful, but I don't understand why this particular pattern would be useful and I can't understand why we need to have two generalizations: Standard Enforcer and Reactor Pattern. Clear Problem Description: Bad Clear Relevance and Consequences: Bad Clear Figures and Illustrations: I don't see why there is rdfs:subClassOf in the diagram so many times instead of the "inheritance" relation. It's too much text in the diagram. Missing Information: citations are missing in this pattern description. This website may be collaborative, but I still believe citations are required if it was based on another pattern, otherwise one could do even more strange things, like simply copy an existing pattern and just change the name of the author. And perhaps the citation is missing in the article that should have come with this pattern as well. Also, the domain is not stated, perhaps it's "general". Overall, it is a very strange pattern. ". Overall, it is a very strange pattern. |
