Property:HasReviewSummary

From Odp

Jump to: navigation, search

This is a property of type Text.


(previous 25) (next 25)

Pages using the property "HasReviewSummary"

Showing 25 pages using this property.

A

AldoGangemi about AquaticResourceObservation +After evaluation by Aureliano, the axioms After evaluation by Aureliano, the axioms in the observation pattern have been distinguished between stable and changing. Stable ones should go with individual patterns involving at least one observation, while changing ones are parts of an observation: 1. give me the resource observations where the exploitation rate is "Moderate fishing mortality" 2. give me the resource observations where the state is "fully exploited" 3. give me the resource observations where the abundance level is "Low abundance" 4. give me the resource observations where the jurisdictional distribution is "Highly migratory" (!!!stable) 5. give me the resource observations where the zone is "Tropical" (!!!stable) 6. give me the resource observations where the vertical distribution (vdist) is "Pelagic" (!!!stable) 7. climatic zone (!!!stable) 8. horizontal dist (!!!stable) However, changing ones do not go all together, in particular, CQs 1,2 go in the same observation, while 3 is independent. same observation, while 3 is independent.
AldoGangemi about ConceptGroup +The pattern tries to provide an OWL repres The pattern tries to provide an OWL representation of a construct used to talk about groups of concepts or fragments of thesauri. I think the pattern is a valid contribution, but needs major revisions in documentation, axiomatization, and relation to other patterns. atization, and relation to other patterns.
AldoGangemi about GearWaterArea +After Aureliano's evaluation, here you nee After Aureliano's evaluation, here you need to link gears to species to water areas, therefore the pattern requires at least three classes, with relations between gears to species, and species to water areas respectively. The synthetic relation can then be instantiated by using SPARQL CONSTRUCT. Alternatively, it can be generated with a SWRL rule, or by using an OWL2 alternate pattern, in which a property chain is defined (best practice). property chain is defined (best practice).
AldoGangemi about Location +This page is a duplicate and should be deleted: the [[Submissions:Place|Place]] pattern page is a complete rendering of the same pattern linked here.
AldoGangemi about SpeciesConditions +After Aureliano's evaluation, this alterna After Aureliano's evaluation, this alternate pattern for species conditions does not seem to catch the intended conceptualization by fishery experts ... in principle however, bathymetric ranges can vary with water area: simply this variability can only appear when we combine species and resource data, therefore it is an empirical finding if this pattern is useful or not, and cannot anyway be derived from either competency questions or source schemata. r competency questions or source schemata.
AldoGangemi about VesselSpecies +After Aureliano's evaluation, here you nee After Aureliano's evaluation, here you need to link vesseltypes to geartypes to species, therefore the pattern requires at least three classes, with relations between vesseltypes to geartypes, and geartypes to species respectively. The synthetic relation can then be instantiated by using SPARQL CONSTRUCT. Alternatively, it can be generated with a SWRL rule, or by using an OWL2 alternate pattern, in which a property chain is defined (best practice). property chain is defined (best practice).
AldoGangemi about VesselWaterArea +After Aureliano's evaluation, here you nee After Aureliano's evaluation, here you need to link vesseltypes to geartypes to species to water areas, therefore the pattern requires at least four classes, with relations between vesseltypes to geartypes, geartypes to species and species to water areas respectively. The synthetic relation can then be instantiated by using SPARQL CONSTRUCT. Alternatively, it can be generated with a SWRL rule, or by using an OWL2 alternate pattern, in which a property chain is defined (best practice). property chain is defined (best practice).
AlessandroAdamou about DisjointnessOfComplement (DOC) +The proposal looks sensible to me, but I d The proposal looks sensible to me, but I do expect that other peers might believe it to be rather trivial, thus I would recommend it for discussion at WOP. It is however essential that this proposal is presented in such a way as to target naive developers. such a way as to target naive developers.
AlessandroAdamou about Inverse n-ary relationship +The authors propose an extension to the N- The authors propose an extension to the N-ary relationship pattern where two major participants are short-circuited by means of an inverse property pair.<br /> While the intent is admirable (though it requires a clearer explanation), such a solution does not seem to take into account possible in-house solutions provided by the ontology language. lutions provided by the ontology language.
AlessandroAdamou about Object with states +The pattern provides a reasonable solution to one of the core issues in ontology modeling, but it should not be standalone and its ontology should be generalised.
AlessandroAdamou about OnlynessIsLoneliness (OIL) +The submission needs to be detailed in sev The submission needs to be detailed in several respects. The pattern proposal itself makes pretty much sense, but end-users should be guided a little more in deciding if and where to apply it. To stretch this aspect to its extremes, WOP could be a suitable place for discussing if applying such a pattern should be a task for humans or software agents. d be a task for humans or software agents.
AlessandroAdamou about Reactor pattern +The pattern brings a nontrivial modeling p The pattern brings a nontrivial modeling problem to the domain of process and workflow representation. 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. Some rather feasible presentation issues in the pattern page should be addressed as well. pattern page should be addressed as well.
AlessandroAdamou about Symmetric n-ary relationship +While the problem this pattern tries to ad While the problem this pattern tries to address cannot go unnoticed in OWL modelling, little explanation is provided as to how it distinguishes from built-in symmetric properties in OWL. As it is, the proposed pattern seems rather awkward for production use, and its naming can be misleading. ion use, and its naming can be misleading.
AndreaNuzzolese about Faceted Classification Scheme +The pattern is well described and presents The pattern is well described and presents an acceptable and good modelling example respect to the Faceted Classification Scheme. The FSC pattern is related to the Normalization pattern and the motivations are clear and they derive from classifying needs. What is not immediatly clear is how eventual issues from the Normalization pattern imply issues in the FSC pattern. Furthermore the approach taken seems to provide the possibility to use different implementation of the Normalization pattern from the suggested one. malization pattern from the suggested one.
AndreaNuzzolese about Normalization +The aims behind the proposal are very clea The aims behind the proposal are very clear to understand and the Normalization pattern can be, with a few revisions, a good solution to them. I agree that in the case of a large polyhierarchy is much better to infer subsumption relationships than hardcode them, but it should be clarify better how the complexity of the reasoning is increased by a lot of new added restrictions, expecially with large data sets of triples. Furthermore adding disjointess can introduce inconsistence in the schema and incoherence in the data. in the schema and incoherence in the data.
AndreaNuzzolese about Reactor pattern +The pattern addresses a relavant problem i The pattern addresses a relavant problem in modeling reactive processes. The problem statement and the solution presented and proposed by the author are clear. The terminology used for naming classes and properties is appropriate with respect to the context. Competency questions proposed are exhaustive for expressing the requirements that should be covered by the patterns. In my opinion there is a lack of usage of existing content pattern. For example the ProcessParameter class can be defined by specializing the Parameter class from the parameter pattern (http://ontologydesignpatterns.org/cp/owl/parameter.owl). I also see an Event as a n-ary relation. This allows to express the Event class by specializing the Situation content pattern. I don't understand the need of the definition of the description object property. If its intent is to express the descriptive context of a concept the Description pattern could be used. Otherwise an annotation property or even the rdfs:comment could be used. I find the existential restriction for the Process class to strict for what is used as a top level class. The author is encouraged to use labels and comments for entities defined in the pattern. ments for entities defined in the pattern.

B

BenedictoRodriguezCastro about Object with states +See: http://ontologydesignpatterns.org/wiki/Reviews:BenedictoRodriguezCastro_about_Object_with_states_2
BenedictoRodriguezCastro about Object with states 2 +The pattern "Objects with States" (OWS) pr The pattern "Objects with States" (OWS) proposes a solution to the modeling scenario in which an object may go through a series of different states, and for each given state different restrictions and implications may apply. The proposed pattern addresses a very recurrent modeling scenario in real world Web applications and puts forward a generic solution, domain-independent with a promising potential for reusability. In terms of functionality, the pattern submitted addresses the targeted modeling scenario. On the other hand, in terms of description and documentation, there are some important aspects captured in the rest of this report that in my view have not been sufficiently documented and discussed. Overall, I think this pattern fits very well the WOP workshop and can provide a very interesting topic of discussion among participants. I would recommend a rating of 1 ("weak accept" or "needs minor revision"). ("weak accept" or "needs minor revision").
BenedictoRodriguezCastro 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 model. 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".
BenedictoRodriguezCastro about TransportPattern +Note to Program Committee: This "Review S Note to Program Committee: This "Review Summary" is the same as uploaded to EasyChair based on the 4.5 pages paper submitted by the authors. The rating of -1 (weak accept) on EasyChair or 0 (needs minor revision) here is based on the content of the paper. The content submitted on this Web portal for this pattern is very poor and leans toward a rating of -1 (reject). --- Note to authors: PLEASE, POPULATE THE CONTENTS OF THE PAPER ON THE CORRESPONDING FIELDS ON THE SUBMISSION PAGE OF THIS WEB PORTAL. --- This pattern submission introduces an Ontology Design Pattern (ODP) for the concept of "Transport" in the domain of Geosciences. The meaning of the concept of "Transport" intended to be modeled is defined. The main elements of the pattern are introduced together with their role and function. The pattern is characterized in general terms so that it could be applied to other domains as well. The authors provide an example of how some of the core elements of the pattern can be extended to represent additional aspects associated with the notion of a "transport event". The strengths and weaknesses of the submission are summarized below: - The Transport ODP is highly relevant to the workshop because the topics discussed fall well within the scope of the WOP event. - The readability of the submission is clear. The originality and contribution of the pattern can be seen as novel because, although anchored as an extension to the Semantic Web for Earth and Environmental Terminology (SWEET) ontology, the proposed representation of the concept of "Transport" as defined in the submission, is new. - The discussion of related work can be significantly improved because, although the submission mentions other ontologies that the pattern extends (i.e. SWEET) or that it can be linked to (i.e. SOS, or GML), it does not state explicitly whether there have been (or not) previous efforts at representing in a Web ontology, the same notion of "Transport" put forward by the authors. - The potential practical utility of the proposed approach is very promising because the pattern is defined in general terms and its representation of a "transport event" could be applied to many domains. However, the documentation of the pattern in the submission hampers its utility because there is not a simple full example of a "transport event" illustrating the instantiation of all elements of the pattern. Some "transport event" examples are mentioned (i.e. river flow, air travel) but the instantiation of the pattern is left to the intuition of the reader. Other examples stated can be complex for those not familiar with their particular domain (osmosis, diffusion, etc.). - The generic schema of the pattern, the naming convention of the core elements and its graphical representations are misleading or unclear because: (a) the names given in the narrative do not align the names given to the corresponding object in the figure (i .e. transportEvent, vs. TransportEvent or referenceFrame vs. ReferenceFrame - which one is it?); (b) the same object in the figure is used to represent classes and properties (both Transport-, and ReferenceFrame are round boxes); (c) what does the arrow "propertyOf" in Figure 1 represents? It is not addressed; (d) what do the different colors chosen in Figure 2 represent? and (e) the choice of the "partOf" relation between core classes in the pattern is never discussed. - The implementation of the pattern provided in [1] seems to contain a bug, likely due to the naming issues identified above. The domain and range in the definition of the property :referenceFrame in [1] is set to the URI :transportEvent (low-case 't'), which is not explicitly defined as a class in the .owl file. However, the URI :TransportEvent (upper-case 'T') is. [1] https://wiki.auckland.ac.nz/download/attachments/52016791/TransportPattern.owl - In terms of evaluation, the authors acknowledged how it could be approached but as stated earlier, there are no clear or real concrete examples of full instantiations of the pattern. Figure 2 suggests how the pattern can be populated or extended but the concepts used (osmosis, diffusion, percolation, etc.) may not be the ideal introductory example as they represent very specific domains and certain degree of experience in them may be required. Overall, a very interesting pattern for a modeling scenario (a transport event) very prevalent in the real world. Even though there are several aspects of the pattern that should be improved in terms of documentation and exemplification as outlined above, the essential conceptualization of the pattern is valid and it could prove an interesting point of discussion at the WOP event. Thus, the recommended rating is 0 (needs major revision) (which I am equating to a -1 -weak reject- on EasyChair). ating to a -1 -weak reject- on EasyChair).
Biological Entities Review ValentinaPresutti +The CP needs to be improved. * All ontolog The CP needs to be improved. * All ontology elements have to be associated with a description. * The domain and range is the same for the three object properties: [[Submissions:Biological_Entities/biological_entity|biological_entity]]. However, there is a local restriction on their usage. It seems to me that domain and range should be personalized for each object properties as the classes you restrict on are disjoint. In other words, you do not want to allow for example the assigment of a value of [[Submissions:Biological_Entities/includesOrder| includesOrder]] for a certain [[Submissions:Biological_Entities/family|family]]. This is now possible as the [[Submissions:Biological_Entities/includesOrder|includesOrder]] property has domain [[Submissions:Biological_Entities/biological_entity|biological_entity]]. * The CP should import the CP annotation schema (http://www.ontologydesignpatterns.org/schemas/cpannotationschema.owl). * Which are the competency questions of this CP? And examples?; tency questions of this CP? And examples?;
BorisVillazón-Terrazas about Define Hybrid Class Resolving Disjointness due to Subsomption +This pattern solves disjointness (caused by subsumption), by defining a hybrid class. It can lead to discussions during WOP.
BorisVillazón-Terrazas about Faceted Classification Scheme +This pattern provides a process to create This pattern provides a process to create an ontology from a Faceted Classification Scheme (FCS) by using the Normalization ODP. There is only one minor thing to the submission, the graphical representation of the example is the same of the process description. So, it would be good to include a graphical representation of the example. a graphical representation of the example.
BorisVillazón-Terrazas about Normalization +This pattern is useful for validating a cl This pattern is useful for validating a classification. The submission needs to be detailed in a few respects: • Arrange the Solution of the description by enumerating the steps: o Indetify the modules o Create the modules, etc • Provide an example (an owl file of the graphical example), o maybe an excerpt of an input ontology, and the resultant ontology after the application of the pattern (the owl file) • Add a link to the Cell type Ontology, I was not able to find it. • As already Catherine pointed out, it would be good to include in the example a disjoint relation. nclude in the example a disjoint relation.
BorisVillazón-Terrazas about Standard Enforcer Pattern +The proposed pattern describes modelling guidelines to describe a standard and the process that enforce the standard.
(previous 25) (next 25)
Personal tools
Quality Committee
Content OP publishers