Property:HasProblems

From Odp

Jump to: navigation, search

This is a property of type Text.


(previous 25) (next 25)

Pages using the property "HasProblems"

Showing 19 pages using this property.

R

RinkeHoekstra about Object with states +* It seems ontologically strange to define * It seems ontologically strange to define 'objects' as classes, whereas the states are individuals associated to *instances* of those object classes using the 'hasState' property. A more pragmatic solution would be to decide that all individuals of type 'Object' are also states. One can then individuate an object through time (i.e. through all its states) by chaining these states together using a property of choice. Another option would be to consider all states that are instances of a certain object class to be states of the same object. The object class then represents the object as it exists through time (perhaps this is closest to the currently proposed pattern) * Secondly, it could be argued that there should not be a strict requirement that the states of an object are distinct individuals. For instance, I can be both married and brown-haired at the same time. Distinct individuals is a design decision that the author should argue for explicitly. * The design pattern does not ensure that individual states are only the state of a *single* object. I.e. the has-state property should be inverse functional. ate property should be inverse functional.
RinkeHoekstra about PeriodicInterval +The pattern is overly simplistic (see summary)

S

StefanoDavid about NegativePropertyAssertions +Some comment: * The pattern seems very us Some comment: * The pattern seems very useful, expecially if used (possible use case) in knowledge systems where is difficult to migrate knowledge bases from OWL1 to OWL2, for different reasons. * the functional syntax seems wrong: According to the W3C specs, it should be NegativeObjectPropertyAssertion(ns:prop ns:i1 ns:i2) * it seems to me more a reengineering pattern, as it relates two similar but different languages. * I am not completely sure that there is an equivalence relation among the LHS and the LHS, so I expect a proof or explanation accompaning it * The modeling problem is well stated, but besides the proposed solution, no documentation is provided (ise cases, scenario, etc.) on is provided (ise cases, scenario, etc.)
StefanoDavid about OnlynessIsLoneliness (OIL) +* I would rephrase the problem statement: * I would rephrase the problem statement: I would suggest to call "problem" the modeling error (which is obviously an Anti-Pattern, as it causes the ontology to become useless), and "pattern" the proposed solution. * There are different hydrontologies in the "Pattern solution example": I would point only to one of them, as they seem very similar, and use it also as use case. * Although the hydrontologies seem to be some official Spanish knowledge bases, I would rather use an english version of a part of them that clearly states the problem, as it is not so comfortable to search in the whole ontology the pattern. * I would extend the definition of this pattern by suggesting that it is allowed the use of multiple restrictions (i.e., C1 subClassOf R only C2, ... ,C1 subClassOf R only Cn) to be combined in a single disjointness axiom, e.g., for those languages, like OWL2, that allow DisjointClasses into a single axiom: C1 subClassOf R only (C2 or ... or Cn); disjointClasses (C2, ... Cn) * "We have categorized them into three groups:". There are no three groups in the remainder, but the description of three classes nder, but the description of three classes

T

TimLebo about LicenseLinkedDataResources +6) Classes versus instances (and punning) 6) Classes versus instances (and punning) Why does the LLDR ontology have an exemplar instance for each subclass of LinkedDataRight? When does one refer to the instance, and when does one refer to the class? When does one instantiate their own instance of the LLDR subclasses of LinkedDataRight? It would seem to me that an instance of Access is a particular occurrence of Access (say, when I downloaded your OWL file). If I did it again, I'd have another distinct instance of Access. See "Consideration of W3C PROV" for the intrinsic parallels between being permitted to do something and actually doing it (in this case, the subclasses of LinkedDataRight are prov:Activities). 9) Prefixes and namespaces The prefix "lldr" was not defined in the paper, nor at prefix.cc. I've since added it to prefix.cc/lldr. http://purl.oclc.org/NET/lldr/ns# The paper did not define the prefix "gr", which was fortunately defined at http://prefix.cc/gr. The properties "hasCurrency" and "hasCurrencyValue" in the example did not have prefixes, so I had to presume they were Good Relations properties. The namespaces in the OWL representation seem to be inconsistent. In the paper, the following classes use the same prefix, but they do not share the same namespace (http://purl.oclc.org/LinkedDataResource, http://purl.oclc.org/NET/lldr#LinkedDataRight). 10) Resolvability The following URIs are mentioned in the OWL representation but do not resolve (they 404) http://purl.oclc.org/access http://purl.oclc.org/Authorisation http://purl.oclc.org/Contract http://purl.oclc.org/derivativeWorks http://purl.oclc.org/distribution http://purl.oclc.org/extraction http://purl.oclc.org/License http://purl.oclc.org/LinkedDataResource http://purl.oclc.org/NET/lldr http://purl.oclc.org/Proposition http://purl.oclc.org/reproduction http://purl.oclc.org/reutilization http://purl.oclc.org/SimpleLicense ization http://purl.oclc.org/SimpleLicense

V

ValentinaPresutti about Context Slices +An inaccuracy that I noticed is that this An inaccuracy that I noticed is that this ODP is a Content ODP while the author refers to it as a Logical ODP. At least according to the taxonomy of ODPs currently used in this portal. Such taxonomy is not a law of course, but provides reasonable distinctions, useful for building a "pattern language" in a community like the one we are building altogether. The motivation why I would define it as a content ODP is that it provides a vocabulary and can be easily put in a partial order hierarchy, such as that of CPs. tial order hierarchy, such as that of CPs.
ValentinaPresutti about NegativePropertyAssertions +I think that the two logical expressions a I think that the two logical expressions are not equivalent. To assert that "i1 is not in the class of things that have value i2 for property prop" is a bit different from asserting that "i2 has not the value i2 for property prop", because in the latter case the assertion is explicit. I think that this argument should be clarified and exhaustively discussed in the pattern description. It seems to me that there is a useless bracket eems to me that there is a useless bracket
VioletaDamjanovic about Classification scheme - path enumeration model - to Taxonomy +The main problem of this pattern can be se The main problem of this pattern can be seen in its reusability. As for each classification scheme that is going to be translated into taxonomy, the path enumeration brings unique concatenations between the tree' nodes. Therefore, the proposed pattern must be uniquely organized according to the specific classification scheme. To my understanding of the problem, changing classification scheme brings new results of the applied path enumeration method. Otherwise, in case of translating wide-known classification cheme into taxonomy, such a pattern can be recommended to be used/reused. tern can be recommended to be used/reused.
VojtechSvatek about Classification scheme - adjacency list model - to Taxonomy +1) Although the semantics of the hierarchi 1) Although the semantics of the hierarchical relation 'may vary depending of the context', there are no alternative modelling options offered; the subclass construct is uniformly used, which has the subset semantics; this may lead to discrepancies if the original resource is e.g. partonomy-oriented. This should at least be commented on, as a limitation of the pattern usage. 2) While the problem description assumes that the original source is structured as tree, the process description has a special provision for non-tree structures. This is confusing. 3) When a new 'ad hoc' class is created, it is not clear if it is to be identified with a standard class such as owl:Thing, or given the URI through some naming convention - I would expect such a convention as natural part of the pattern. Text-level issues: - what is caparentID? - the last diagram (at example level) is trivial and could safely be omitted el) is trivial and could safely be omitted
VojtechSvatek about ConceptTerms +It is not clear what a compound non preferred term looks like and why it is only made of preferred terms. The reification of the relation between a concept and the terms should be clearly justified. The scenario is too brief.
VojtechSvatek about Context Slices +Just as outlined above.
VojtechSvatek about EventProcessing +I don't see any major problems. Only some details of the pattern should be clarified to ensure its proper use. The diagram also lacks classes SensorOutput and EventObjectPart, which are listed in the glossary.
VojtechSvatek about Faceted Classification Scheme +I don't like the phrase 'class that repres I don't like the phrase 'class that represents a subset of the... class', which the author uses. More formally, we should say that the *interpretation* of one class is a subset of the *interpretation* of the other class (i.e. not of the class itself). Or, most simply (and preferably) in the OWL context, we can say that one class is subclass of another. While the categories in a FCS are defined as mutually exclusive and exhaustive, the present example does not seem to fulfill this, in particular for the Brand Name and Scent facets, which can hardly be exhaustive. As concerns mutual exclusivity: the proposal does not explicitly state that the object properties representing the facets (such as hasAgent) have to be functional. Why? h as hasAgent) have to be functional. Why?
VojtechSvatek about PeriodicInterval +It is necessary to distinguish between 'ga It is necessary to distinguish between 'gap' (the distance between an end and a start, for subintervals) and 'period' (normally, the distance between *two* starts or *two* ends). In fact, the given pattern could be generalized to that of a periodic interval with regular starts and variable length - e.g. an executive meeting that always starts on Wednesday 1pm but takes as much time as needed. One could even imagine the opposite case, e.g. preparation of coffee for the meeting can start (variably) in advance but always ends when the meeting starts - for it to be drunk suitably warm :-) In the pattern description it is not even clear if the 'start' and 'end' refer to start/end of the whole non-convex interval (start: Tuesday, x-th January, 2010, 0:00) or of the subinterval (start: Tuesday, 0:00; with year 2010 as externally defined context). year 2010 as externally defined context).
VojtechSvatek about Reactor pattern +I did not notice any technical problem proper. The modelling seems sound.
VojtechSvatek about SimpleOrAggregated +There is at least one inadequacy in the pa There is at least one inadequacy in the pattern description. The author claims to model that an aggregated individual is "made up of several individuals of the same concept". This is however clearly not (necessarily) the case, as there is no guarantee that the individuals gathered in an aggregated object are of the same class within themselves and/or wrt. the aggregated object! For each specialization of this pattern, such a requirement would have to be stated explicitly, i.e. not inherited from the pattern itself. There is a typo: instanciate. I also wonder if Spanish translations within the Elements descriptions are not a bit distracting. ts descriptions are not a bit distracting.

W

WimPeters about ConceptTerms +The pattern has been used in various scena The pattern has been used in various scenarios, and is from that perspective interesting to discuss. The model, which has been re-engineered directly from a terminological standard model, is too simple to express many linguistic notions that contribute to the quality of information extraction. It is very important to acknowledge that the pattern fits into a range of proposed standard formats for the expression of concept labels in terms of preference and constitution, such as SKOS, TBX, TMF, LMF, LIR and LingInfo. It is only after the inclusionof these patterns that it is possible to have a proper discussion of the merits of this pattern on the basis of a comprehensive comparison. n the basis of a comprehensive comparison.
WimPeters about Define Hybrid Class Resolving Disjointness due to Subsomption +Once a subclass is to be defined as a subc Once a subclass is to be defined as a subclass of two disjoint superclasses, this pattern offers a work-around after a more fundamental question has been answered with "yes": Are the two superclasses still to be considered as disjoint? This is a non-trivial decision, which is borne out by lower than expected levels of agreement between experts (see http://www.eswc2007.org/pdf/eswc07-voelker1.pdf). In description logics two classes are considered as disjoint iff their taxonomic overlap, i.e. the set of common individuals, must be empty in all possible worlds. As soon as there exists an instance in the extensions of two disjoint superclasses, the engieer is confronted with the following choices: 1. the disjointness axiom should be deleted, which will negatively affect consistency checking and the automatic evaluation of individuals in a knowledge base with regards to a given ontology (again see (http://www.eswc2007.org/pdf/eswc07-voelker1.pdf)) 2. the proposed pattern should be used. This pattern allows to maintain the original disjoint superclasses while indirectly allowing an instance to be in the extension of both. This goes against the principle of disjointness, but may be convenient in the case where the ontology is imported from another URI. The pattern defines a hybrid class as a union of the definitions of the disjoint classes. The proposers should indicate more precisely what these definitions consist of. Do they consist of all properties and restrictions? Is this equivalent to creating a class AnimalOrPlant, or AnimalAndPlant? Is there a difference between the two? Maybe a third option to be taken into account in the discussion is the introduction of degrees of disjointness. e introduction of degrees of disjointness.
WimPeters about Enlarge Class Definition for Resolving Disjointness due to Subsomption +The problems and discussion points associa The problems and discussion points associated with this pattern are the same as those mentioned for the "Define Hybrid Class Resolving Disjointness due to Subsomption" pattern. The additional problem I see with this particular pattern is that, once the definition from the disjoint superclass has been added, the subclass relation between the enriched subclass and its original superclass may be compromised. ts original superclass may be compromised.
(previous 25) (next 25)
Personal tools
Quality Committee
Content OP publishers