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.
G | |
|---|---|
| GerdGroener about Classification scheme - path enumeration model - to Taxonomy + | The pattern is quite complex for a very si … The pattern is quite complex for a very simple ontological modelling approach, i.e. represent parent and children relations with subclass relations of concepts. It seems that the process description and process example are executed in different directions: the process description starts with the general concept (parent node in the tree) and then considers the children nodes (sub-concepts), whereas the process example description starts with the subclasses (more special classes) and continues with the more general classes. d continues with the more general classes. |
| GerdGroener about DisjointnessOfComplement (DOC) + | For acceptance the pattern needs further explanations why it is beneficial to use disjointness instead of negation. |
| GerdGroener about Inverse n-ary relationship + | As already said, the main problem is that this is not really a n-ary relation. |
| GerdGroener about SimpleOrAggregated + | I was a bit distracted by the terms "non-transitive fashion". What is non-transitive? Are the aggregated objects non-transitive connected? Is it relevant or why is it relevant? This should be clarified in the final version |
| GerdGroener about Standard Enforcer Pattern + | As mentioned above, the presentation needs … As mentioned above, the presentation needs some improvements: - Figure 1: Text is missing, some annotations are cut - Explanation of modelling principles (Explain modelling and design decisions of the patters, i.e., explain the modelling rationale of Figure 1. plain the modelling rationale of Figure 1. |
| GerdGroener about SynonymOrEquivalence (SOE) + | Due to the simplicity of the pattern I doubt that the notion of a design pattern somehow changes to a collection of simple modeling primitives. |
H | |
| HenrikEriksson about Partition + | The pattern documentation needs improvements. Examples should be added. |
J | |
| JoseEmilioLabraGayo about LicenseLinkedDataResources + | The authors declare that they relate licen … The authors declare that they relate license, author, agent, resource and condition. It is not clear if condition is the same as "cc:Requirement". If it is, I would advise to clarify or to define a property "lldr:Condition". Although reusing existing properties can be a good practice, if those properties have different meanings, it may be better to define new properties with a more specific meaning and relate the new properties to the others. It is not clear if the authors separate instances and classes. It is also not clear the granularity of their proposal. The goal is to add licensing information to a statement (in the PDF document they use a partial statement about google stimated stock price) or about a dataset, or both. The submission does not contain OWL examples. The examples in the PDF paper are very simple. examples in the PDF paper are very simple. |
L | |
| LuigiIannone about OnlynessIsLoneliness (OIL) + | I would add some natural language description of the problem example to the bare OWL code. |
M | |
| MariCarmenSuarezFigueroa about ConceptTerms + | The main problem is that author does not provide reference to existing linguistic models that already represent this kind of information (such as the LIR model). |
| MariCarmenSuarezFigueroa about Enlarge Class Definition for Resolving Disjointness due to Subsomption + | The main problem for me is due to the example provide in the pattern. It is not clear that such situation should be represented having a class missed different domain elements. |
| MariCarmenSuarezFigueroa about Enlarge Class Definition for Resolving Disjointness due to Subsomption 2 + | The main problem for me is due to the example provide in the pattern. It is not clear that such situation should be represented having a class missed different domain elements. |
| MariCarmenSuarezFigueroa about Literal Reification + | Apart from the issues already commented by … Apart from the issues already commented by Olaf, I would like to mention that at some point it is not clear enough the need of having this kind of pattern. The authors could include more description of the real need and/or real problems in which this kind of solution is necessary. In addition, this could be related with some parts of the LIR model, in which different labels can be associated to a concept as well as different meanings and related contexts. s different meanings and related contexts. |
| MariCarmenSuarezFigueroa about Normalization + | Apart from the problems already pointed ou … Apart from the problems already pointed out by Catherine and Boris, I would like to mention that the solution has also inconvenience that should be included in the description. For example, sometimes to state explicitly the hierarchy is better than provide axioms to implicitly define it (e.g. Naïve developers can include errors in the axioms). elopers can include errors in the axioms). |
| MariaPoveda about OOPMetrics + | Main comments: .- The domain of the relat … Main comments: .- The domain of the relationship "hasMetric" is set as the intersection of serveral classes, namely OOPClass, OOPProject, OOPMethod and OOPPackage. I think it should be defined as the union of theses classes so that if a instance holds this property it is not classified as instance of all these types, that might be disjoint, when running a reasoner over the ontology. .- The CPAnnotation schema is not imported in the OWL building block as stated in the call. It would be great if the pattern were annotated using such a schema. .- There are no labels nor comments in the OWL code. Minor comments: .- The already existing domain "software" should be added to the domains field. .- The figure could be improved by including the datatype properties. oved by including the datatype properties. |
| MariaPoveda about Template Instance + | In my opinion this pattern could be a reen … In my opinion this pattern could be a reengineering ontology pattern rather than a content pattern. It does not provides solutions for any particular Competency Question or modelling problem. In addition the associated building block does not seem to be really reusable. As it only contains one annotation property, it could be easier to reproduce the building block in an ontology rather than to reuse the owl file attached to the pattern. Finally, it would be nice to know the rationales for defining "isTemplate" as an annotation property (that has the value True) instead of for example a boolean datatype property. f for example a boolean datatype property. |
| MariaPoveda about TransportPattern + | My main problems about this pattern are: … My main problems about this pattern are: 1) The solution proposed is that general that needs a lot of effort to extend and specialize it so that the proposed competency questions could be answered. 2) The authors do not reuse or mention the already existing pattern "Move" ention the already existing pattern "Move" |
| MartaSabou about Term-based thesaurus to lightweight ontology – record-based model + | Minor error in a graphical representation. |
| MathieuDAquin about ConceptGroup + | The general issues I see here concern clar … The general issues I see here concern clarity and possible usage. The first thing is that I am not sure what is meant by concept here. Does it corresponds to the concept of an ontology? In this case shouldn't it be related to owl:Class in the OWL description? This would cause a number of issues at the logical level, in particular, if Group is a concept. This needs to be made clear in my opinion. Also, Group should be called ConceptGroup. I don't really understand the difference between subgroup and narrowerThan. Isn't a subgroup narrower? Finally, I don't see a clear application for this pattern as is. clear application for this pattern as is. |
| MathieuDAquin about DisjointnessOfComplement (DOC) + | This does not fit the usual design pattern … This does not fit the usual design patterns which are meant to be reused, but correspond to a pattern that should not be reused in cases where it is does not express the intended meaning. In addition, I am not actually convinced with the relation between the anti-pattern and the solution. The one to use is depends on what need to be expressed and I am not convinced that the one proposed corresponds to the one most often wrongly applied. nds to the one most often wrongly applied. |
| MathieuDAquin about Xsd:sequence embedding + | I don't see what format level consideration should be included in design pattern definition. Also, the ontology representation is not clear.. is it only a partOf pattern. The notion of sequence does not appear. |
O | |
| OlafNoppens about Inverse n-ary relationship + | There are two problems: first, it's the name as mentioned above, second I would recommend to use the same notation as in the W3C n-ary relationship which is cited. This would make the difference and the understanding clearer. |
| OlafNoppens about Symmetric n-ary relationship + | As already said the main problem is the semantics of a "symmetric n-ary relationship". It also lacks for an explanation/proof of the implementation (which is not clear for me). |
P | |
| PierluigiMiraglia about Term-based thesaurus to lightweight ontology – record-based model + | 1: Although labelled as 'lightweight' by t … 1: Although labelled as 'lightweight' by the author, the resulting ontology is OWL Full. Is this as intended? This is a common issue in this context and seems worth clarifying. Most people don't have in mind OWL Full when considering lightweight ontologies. 2: Would it not be more natural to transition a term-based thesaurus to a SKOS formalization, and then map skos:Concepts terms to classes (or individuals) in an ontology? This may allow flexibility in dealing with the aforementioned OWL Full problem. 3: Is it typically desirable to turn BT/NT relations into transitive sub/superclass relations? This pattern, as written, assumes it is, regardless of the context or purpose of the intended deployment. Again, the SKOS specs proceed more carefully. It may be worth to consider not only an example of applying this pattern, but also a use case -- i.e. an example of why one might want to apply it. 4: In many thesauri the UF relation is used for synonymous term strings (i.e. synonyms in a synset) rather than self standing terms. It seems that would be a simpler solution, too. 5: The graphical charts could be clearer in representing iteration over the NT terms of a term created (rather than just say 'repeat', use a cyclic graph for that part of the chart). cyclic graph for that part of the chart). |
R | |
| RimDJEDIDI about Classification scheme - adjacency list model - to Taxonomy + | 1- The non-ontological resource (adjacency … 1- The non-ontological resource (adjacency list model) re-engineered by this pattern is described as a rooted tree of concepts grouped by some particular degree of similarity. But it is stated that the semantics of hierarchical relation between concepts may vary depending on the context. So, if the relation between adjacency list entities related by a linking column (and expressed by the column title) is more rich than a kind of similarity or a generalization, re-engineering it to a taxonomy classification (mapping the relationship to a subClassOf relation) may reduce the original semantic relation between concepts. 2- There is no reference to the multi-inheritance case, however it is implicitly supported by the process. It should be explicitly clarified whether it is considered in this re-engineering or not modeled in a adjacency list. 3- Cyclic relationship: as a consequence to the first problem described above, a mutual relation between adjacency list concepts may lead to cyclic relation in the taxonomy when applying the process. The hierarchical structure of a taxonomy is typically organized by a subClassOf relation. So, cyclic relation will lead to confusing modeling of subClassOf, equivalent and symmetric semantic relations. uivalent and symmetric semantic relations. |
