Welcome to the CB-NL Wiki » Modeling Guide » Modeling Approach

Changes for document Modeling Approach

Last modified by Linda van den Brink on 2015/04/29 09:09
From version 18.1
edited by Linda van den Brink
on 2015/04/23 09:40
To version 19.1
edited by Linda van den Brink
on 2015/04/23 09:53
Change comment: Removed original dutch text on design patterns.

Content changes

... ... @@ -273,11 +273,11 @@
273 273
274 274 Design patterns are fixed or preferred methods for doing things. The following design patterns apply; the list may grow in time.
275 275
276 -1. Design pattern: natural-language constructions are always given a language code. (alle talige constructies krijgen altijd een taalcode.)
277 -1. Design pattern: We use broadly accepted forms of RDF, having a meaning as close as possible to the intended construction, and for which reasoning (axioma) is available to enforce the correct implementation. We gebruiken breed geaccepteerde RDF vormen, die qua betekening zo dicht mogelijk liggen bij de bedoelde constructie, en waar reasoning (axioma’s) voor beschikbaar is om de correcte toepassing af te dwingen.(We gebruiken breed geaccepteerde RDF vormen, die qua betekening zo dicht mogelijk liggen bij de bedoelde constructie, en waar reasoning (axioma’s) voor beschikbaar is om de correcte toepassing af te dwingen.)
278 -1. Design pattern: For every intended construction, we apply only one corresponding form of RDF. This avoids double maintenance. (we gebruiken voor iedere bedoelde constructie maar 1 RDF vorm. We vermijden zo dubbel beheer.)
279 -1. Design pattern: Whenever necessary, we add axioms which do not alter the original intention of the RDF form but strengthen reasoning and enable integrity checks. We do this also for external constructs, but accompanied by a clear explanation and in such a way that de-activation of these axioms does not alter the correctness and completeness of the ontology.(we voegen waar nodig axioma’s toe wanneer dit de oorspornkelijke intentie van de RDF vorm niet verandert maar reasoning (en daamee integriteitscheck) versterkt. We doen dit ook op externe constructies, maar met duidelijke uitleg, en zo, dat het de-activeren van deze axioma’s de juistheid en volledigheid van de ontologie niet beïnvloedt.)
280 -1. Design pattern: Whenever possible, RDF forms are chosen that can be validated during editing by active reasoners. When impossible, validation is done later using SPARQL queries and reports. (waar mogelijk worden keuzes gemaakt die tijdens bewerking, via actieve reasoners, kunnen worden getoetst, en dus als niet anders kan, dan later via Sparql queries en reports.)
276 +1. Design pattern: natural-language constructions are always given a language code.
277 +1. Design pattern: We use broadly accepted forms of RDF, having a meaning as close as possible to the intended construction, and for which reasoning (axioma) is available to enforce the correct implementation.
278 +1. Design pattern: For every intended construction, we apply only one corresponding form of RDF. This avoids double maintenance.
279 +1. Design pattern: Whenever necessary, we add axioms which do not alter the original intention of the RDF form but strengthen reasoning and enable integrity checks. We do this also for external constructs, but accompanied by a clear explanation and in such a way that de-activation of these axioms does not alter the correctness and completeness of the ontology.
280 +1. Design pattern: Whenever possible, RDF forms are chosen that can be validated during editing by active reasoners. When impossible, validation is done later using SPARQL queries and reports.
281 281
282 282 How to implement design patterns in OWL is described [[here>>Design Patterns]].
283 283

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 5.3 - Documentation