Property:IsBestPractice
From Odp
This is a property of type Text.
(previous 25) (next 25)
Pages using the property "IsBestPractice"
Showing 22 pages using this property.
M | |
|---|---|
| MartaSabou about SynonymOrEquivalence (SOE) + | Good. |
| MathieuDAquin about ConceptGroup + | The current form of the pattern doesn't seem to relate with best practices, and at least in naming, is not really appropriate. |
O | |
| OlafNoppens about Inverse n-ary relationship + | good |
P | |
| PierluigiMiraglia about Term-based thesaurus to lightweight ontology – record-based model + | The solution presented is fairly natural, and I would guess pretty common. However, there are alternatives, and there should be more considerations of costs v benefits in regard to the alternatives as well. |
R | |
| RinkeHoekstra about OOPMetrics + | It is an ontology for measuring best practices in OOP, which is good. However, the ontology itself does not follow best practices (lack of labels, limited documentation etc. |
| RinkeHoekstra about Object with states + | The pattern does not really take into acco … The pattern does not really take into account the best practices around this subject. Objects and their states are discussed at length in the literature (though mostly philosophically inspired). It is fair enough that the author takes a pragmatic approach (which is laudable), but consulting related work would most likely improve the quality of the pattern. likely improve the quality of the pattern. |
| RinkeHoekstra about PeriodicInterval + | The pattern does not present a best practice |
S | |
| StefanoDavid about NegativePropertyAssertions + | It can be seen as a good pattern to express (as stated by the author) a logical construct not present in one language |
| StefanoDavid about OnlynessIsLoneliness (OIL) + | High, as it solves modeling mistakes. |
T | |
| TimLebo about LicenseLinkedDataResources + | 4) Consideration of W3C PROV After assert … 4) Consideration of W3C PROV After asserting some LLDR, a natural question to ask is "did anyone violate some rights?". The only way to answer that is to know what happened. The proposed pattern offers how to model what *can* or *can not* happen, but a natural and necessary complement is to also model what *happened*. Within Linked Data, the ontology to model what happened is undoubtedly W3C's PROV Recommendation. While one could claim that PROV integration with LLDR is "future work", would it not be better to phrase LLDR in terms of PROV in the first place, so that rights violation would be a simple matter of querying the same concepts under some addition constrains provided by LLDR? See comment "Use of Reasoning" below. 3) Level of reuse The proposal claims value in LLDR by its "reuse" of existing vocabularies CC, FOAF, ACL, DCTerms, and VoID. However, it does not provide reassurance that each is being reused acceptably according to the original ontology. It also does not provide justification for why the remaining portions of the reused ontologies are not also used in this pattern. So, I am forced to do so here to gain the confidence that I should be provided by the proposed pattern and its description. ACL is reused by grouping acl:Access as a lldr:LinkedDataRight. But, why was acl:Authorization and acl:InformationResource not reused by LLDR? They both seem to apply to your requirements. acl:Authorization is either a subclass of lldr:RightsExpression or is equivalent. lldr:LinkedDataResources are acl:InformationResources, and the LLDR pattern should apply more generally to the latter. CC is reused by cc:License, cc:Requirement, cc:Permission, cc:Prohibition, cc:requires, cc:Reproduction, cc:Distribution, and cc:DerivativeWorks. The ontology does not mention cc:requires, although it appears in the example in the paper. The paper diagram shows that cc:Requirement is a subclass of lldr:RightsExpression, but cc:Requirement does not appear in the OWL. The comment on lldr:Reutilization sounds a lot like its superclass cc:Distribution, what's the difference? Do cc:Reproduction,Distribution,DerivedWorks not relate to cc:Permission,Requirement,Prohibition in the CC ontology? I find it hard to believe that they'd be isolated, but cannot spend the time to dig into CC for this review. I will omit a complete comparison to CC in this review, but it should be done by the authors. FOAF is reused by using foaf:Agent. Although this is a straight forward choice, the FOAF definition is known to have problems when using it to perform reasoning. VoID is reused because LLDR only applies to LinkedData resources and VoID is the primary way to talk about RDF datasets. But, since LLDR is a "pattern", it should apply to any kind of information resource (like ACL's) and not just linked data. DCTerms is reused by dcterms:license. It's not clear how this is a part of the pattern. However, if the directed qualification pattern were used, the relation between dcterms:license and a RightsExpression would make perfect sense. See comment "Qualification pattern". In this case, RightsExpression would be a subclass of rdf:Statement with restriction onProp rdf:predicate value dcterms:license. With this, you'd be qualifying the license of the resource with respect to the agent, use, etc. ource with respect to the agent, use, etc. |
V | |
| ValentinaPresutti about Context Slices + | The pattern is described and can be read a … The pattern is described and can be read as a best practice, in the sense that it provides a clear, small, and easy to apply solution to a recurrent problem. My understanding of the pattern is that it provides a nice vocabulary and specific axiomatization for the usage of the n-ary relation pattern when dealing with modeling contexts. This is perfectly fine, but in the text it seems that the author refers to some additional logical benefit that cannot be obtained with other solutions. I recommend to clarify this aspect. tions. I recommend to clarify this aspect. |
| VioletaDamjanovic about Classification scheme - path enumeration model - to Taxonomy + | The proposed pattern is definitely an interesting solution to the translation of classification scheme into taxonomy. |
| VojtechSvatek about Classification scheme - adjacency list model - to Taxonomy + | The problem is simplified such that the current pattern looks like the only straightforward solution. In reality a more complex solution would be needed. |
| VojtechSvatek about Context Slices + | For the problem in question, this (or just slightly modified) pattern seems to be best practice. |
| VojtechSvatek about EventProcessing + | The pattern builds on existing upper-level ontologies, adding a lightweight extra layer. It could thus become a part of best practices. |
| VojtechSvatek about Faceted Classification Scheme + | Yes, I would see this pattern as best practice in the given context. |
| VojtechSvatek about PeriodicInterval + | The alternatives should be explicitly described. |
| VojtechSvatek about Reactor pattern + | Alternative solutions are not discussed. |
| VojtechSvatek about SimpleOrAggregated + | Could be seen as best practice. |
W | |
| WimPeters about ConceptTerms + | The pattern does represent a best practise, since it is based on a standard. There are may alternative solutions, which need to be modeled as alternatives, and linked to this pattern in order to maximize coverage and usage. |
| WimPeters about Define Hybrid Class Resolving Disjointness due to Subsomption + | I am not aware of best practise for the solution of this problem. |
| WimPeters about Enlarge Class Definition for Resolving Disjointness due to Subsomption + | none that I know of. |
