Property:HasProblems
From Odp
This is a property of type Text.
(previous 25) (next 25)
Pages using the property "HasProblems"
Showing 25 pages using this property.
A | |
|---|---|
| AldoGangemi about ConceptGroup + | The lack of a concrete example makes the p … The lack of a concrete example makes the pattern difficult to understand. From the technical viewpoint, there are some problems: 1) the object properties lack inverses: this is a bad practice; inGroup lacks an inverse at all, while BT is not made inverse of NT, and subGroup of superGroup 2) the reification of BT-NT, and subGroup-superGroup mught be due to the need of creating inverse object properties: in this case, this is a bad practice. If reifications are needed for other reasons, this is not clear 3) the structuringAssociationType object property seems used to link concept groups to the reification of BT-NT. Why is is needed? The use case behind this object property is unclear ase behind this object property is unclear |
| AlessandroAdamou about DisjointnessOfComplement (DOC) + | Nothing in particular as for the pattern itself. For the presentation, see below. |
| AlessandroAdamou about Inverse n-ary relationship + | The pattern naming can be confusing, since … The pattern naming can be confusing, since it somehow looks more like a "bridged" or "short-circuited" n-ary relationship.<br /> In OWL2, there should be some consideration for property chaining, which could link the properties that hold between the main actors and the N-ary relationship class. This would partly offer an in-house solution to the issue addressed as well as an elegant way to link relationships with one another, though it would probably require the intervention of reasoners. bly require the intervention of reasoners. |
| AlessandroAdamou about Object with states + | * the pattern has no dependencies, whereas … * the pattern has no dependencies, whereas it seems to have strong ties with catalogued patterns such as Situation (of which it seems to be a suitable extension) and Parameter; * the partitioning of states, objects with states, and their resulting properties, into exactly three items is hardwired in the ontology itself. As it is used to exemplify its usage, it should not appear in the core ontology. it should not appear in the core ontology. |
| AlessandroAdamou about OnlynessIsLoneliness (OIL) + | Mostly to deal with pattern presentations. Please see below and also see my review for Disjointness of Complement (DOC). |
| AlessandroAdamou about Reactor pattern + | - 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" |
| AlessandroAdamou about Symmetric n-ary relationship + | The pattern as it is conceived seems to be … The pattern as it is conceived seems to be trying to cover all with a short blanket. While it does eliminate the redundancy of providing property pairs, it lends itself to the risk of an uncontrolled growth of n-ary relationship subclasses. What happens if we need to determine the distances between lots of places? Would this result in a new class for each distinguished value for a distance between to places? <br /> Talking about "n-ary" symmetry sounds a bit confusing, as symmetry is commonly supposed to hold for binary relationships. The way the pattern is built, "binary" instead of "n-ary" could perhaps suit better. tead of "n-ary" could perhaps suit better. |
| AndreaNuzzolese about Faceted Classification Scheme + | Related to the issues from the Normalization pattern. |
| AndreaNuzzolese about Reactor pattern + | There is a typo in the hasEnvironemntalCondition object property that should be hasEnvironmentalCondition. Labels and comments should be defined for each class and property in the pattern. |
B | |
| BenedictoRodriguezCastro about Object with states 2 + | See sections: - "Relation to Other Patterns", - "Overall Understandability", - "Clear Relevance and Consequences", - "Clear Figures and Illustrations", and - "Missing information". |
| BenedictoRodriguezCastro about Template Instance + | The description of the pattern in abstract … The description of the pattern in abstract terms appears as a very insteresting optimization to avoid the unnecessary repetition of a set of instances that occur multiple times in the ontology model. In that sense, it is a very useful and practical modelling idiom. On the other hand, there are some aspects that hinders the applicability and understandability of the pattern, such as: (a) lack of a concrete example of the pattern supported by a corresponding graphical representation (b) the reusable building block in OWL provided contains only the annotation property mentioned in the pattern (c) the examples OWL files also refer to the implementation of the pattern in abstract terms (d) the known uses provided simply point to the landing website of two medical classifications but it is not clear how the pattern is actually used by these classification resources. Therefore, because of the reasons above, I would recommend to provide a major revision of the pattern to address them. r revision of the pattern to address them. |
| BenedictoRodriguezCastro about TransportPattern + | See section "Review Summary". |
| BorisVillazón-Terrazas about Faceted Classification Scheme + | The pattern propose a very interesting solution for creating an ontology from a FCS. |
| BorisVillazón-Terrazas about Normalization + | This pattern is useful for validating a classification. |
| BorisVillazón-Terrazas about Standard Enforcer Pattern + | The author has to explain, in a better way … The author has to explain, in a better way, the modelling principles of the Figure 1. One minor comment, regarding the OWL file. Probably this is for all patterns. The community is adopting TURTLE as human-readable syntax for RDF, so I would prefer to have the patterns in TURTLE instead of RDF/XML. the patterns in TURTLE instead of RDF/XML. |
| BorisVillazón-Terrazas about Template Instance + | The pattern is very useful when we need to avoid the unnecessary repetition of a set of instances that occur multiple times in an ontology. However, the pattern lacks of a real example. |
| BorisVillazón-Terrazas about TransportPattern + | I think the pattern needs a bit more explanation and probably a very interesting use case description. |
| BorisVillazón-Terrazas about Xsd:sequence embedding + | The xsd:sequence implies also the order of the contained elements. The pattern does not take into account this feature. |
C | |
| CatherineRoussey about SimpleOrAggregated + | No information is given on the meaning of … No information is given on the meaning of the aggregation property: is it a hasMember, hasPart, hasComponent property? maybe the aggregation can be replace by any of them... and does this property transitive or not? Why do you thing that all the objects can be classified as a simple one or an aggregated one? First I would rather fixe a subClassOf relationship between ObjectByCardinality and Object... Depend of the point of view (the scale) an object can be classified as simple or not... An organ is a simple object or not? Organ is composed of cells and cell is composed of... if an individual O has two aggregated Members O1 and O2 asserted in the ontology... Moreover if O1 is fixed as same as O2... what do you expect from the reasoner? What's happen if instead 02 is also an aggregatedMember of O1? tead 02 is also an aggregatedMember of O1? |
E | |
| EnricoDaga about Xsd:sequence embedding + | This pattern is named XSD:Sequence embeddi … This pattern is named XSD:Sequence embedding. The 'sequence' indicator in XSD means not only a group of element into another (as xsd:all or rdf:Bag), but implies also the fact that those elements must be in a particular order, and this order cannot change, or if it changes, or it is lost in the reengeneering process, the result is a loss of information (see, for example [http://www.w3schools.com/schema/schema_complex_indicators.asp]). The semantic of the 'partOf' ObjectProperty defines pure meronimy relation. It is probably the good solution for representing the containment of one or more XML elements into another (also rdf:Bag could be reengineered in an ontology in the same way). In the XSD case, it can be used to reengineer the 'All' order indicator instead of the 'sequence' one. Additionally, the example refers to the case in wich the order of the embedded elements is not important. There are two possibilities: 1) The pattern should be renamed, removing the relation to the 'sequence' and changing it into 'meronimy' or 'partitive' relation, taking the example as meaningful 2) The sequence is a crucial point of this pattern, and this should be better motivated in the example and description of the process. he example and description of the process. |
| EnricoMotta about Context Slices + | There are no errors in the conceptual desc … There are no errors in the conceptual description of the pattern, however the OWL version of the pattern does not load properly in either topbraid or neon. As an additional minor point, I suspect the arrow ceoOf in the graphical representation is going the wrong way. cal representation is going the wrong way. |
| EnricoMotta about Literal Reification + | The OWL source does not load properly in either topbraid or neon. This should be fixed. |
F | |
| FrancoisScharffe about Classification scheme - adjacency list model - to Taxonomy + | Clearly stated. |
| FrancoisScharffe about ConceptGroup + | The problem of modeling group membership is important |
| FrancoisScharffe about Enlarge Class Definition for Resolving Disjointness due to Subsomption + | The patterns suggests to enlarge class def … The patterns suggests to enlarge class definition. However afterwards what about disjointness of original siblings (from example Animal and Plan). Enlarged class will still be disjoint with the Animal class or not? It is not clear for me now and it would be good to discuss this in the pattern description. This pattern is strongly related to pattern 'Define Hybrid Class Resolving Disjointness due to Subsumption' which should be explicitly mentioned there (they are from the same author). Perhaps it would be even better to have these two solutions for one problem in one pattern description with clear distinguishing when which solution should be applied (also wrt. an application of ontology which influence modeling choice). Defining hybrid class seems to me be better solution. Therefore it would be good to mention arguments against and in favor of these two solutions of one specific problem. General remark: If I remember well there is one category of ODP patterns 'Change Management Patterns' and sub-category 'Inconsistency pattern'. It seems it perfectly fits into this category. But perhaps it is not in official catalog so far. haps it is not in official catalog so far. |
