This document is complemented by a "discussion on recommendations to increase knowledge reuse" that I wrote in March and in which I detail some viewpoints.
Each introduced relation should be defined. If contexts (i.e. meta-statements) can be used, only one primitive relation is needed and it is binary (John Sowa called it LINK in his 1984 book). If contexts are not used, a ternary primitive relation may be useful.
There should be one subtype hierarchy (hence with one one top) which include all the declared concept type.
The meaning of the subtype and instance relations should be respected. The criterias of the OntoClean methodology (e.g. identity, unity, ...) help to check that.
The "proper_subtype" relation and the "identity" or "equivalence" relations should be prefered to the general "subtype" relation. Same note for other partial order relations.
Organizing types via the "subtype" relation should be prefered to organizing via the "instance" relations, whenever adequate.
The classic knowledge representation structures (relation signatures and cardinalities, open/complete subtype partitions, exclusion links, ...) should be used whenever adequate.
New ontologies should re-use directly or indirectly reuses a top-level ontology that defines notions of collection, state, process, event, spatial_entity, physical_entity, temporal_entity, information_entity, property and measure. The ontological assumptions (e.g. see the WonderWeb D18 for a nice summary) should be explicit.
If a 3D approach is used (instead of a 4D approach), temporal constraints should be represented in the statements that require them. Temporal constraints may be represented using contexts, or adding a time parameter to some relations type. The first option is easier for people to represent natural language sentences. The second option is easier for current theorem provers to reason with.
Types should represent, and be named after, the underlying nature of an object, not the role it plays in a particular context".
The reading and naming convention generally advocated by frame-based or graph-based languages should be preferred (hence the use of a noun or a nominal form for an identifier, without "has_", "is_" or "_of" inside this identifier; e.g. "parent", not "child_of", not "has_parent" nor the verbal forms "parenting" and "parents"). However, if this convention is not respected, it is better to use "_of" to make the parameter ordering explicit than to use a different parameter ordering without signaling it in the identifier.
Identifiers that reuse common words should use the same capitalization. To separate words, it is better to use underscore than the Intercap style. When European words are re-used, a first capitalized letter should be the mark of an individual (not a type). Thus, "member_of_the_ONU" is better than "MemberOfTheONU", "memberOfTheONU", "ONU_member" and "ONUMember".
Identifiers for second-order types should include "_type" or "_class" at the end, as in "binary_relation_type" (intead of "Property").