General Actions:
... | ... | @@ -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. |
|
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. |
|
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 |