The conventions specified above can and should apply to the lexicalized forms occurring in ontologies for the purposes of display (or human interpretation). However, because ontologies are meant to be machine interpretable, other considerations, in addition to those already mentioned, come into play when establishing lexical conventions. For one thing, they must comply with legal XML syntax. For another, ontologies make distinctions beyond the terms and relations characteristic of thesauri, such as property types, instances and classes, and so on. Consequently, separate conventions are necessary for ontology development.
General conventions
Case
Despite the widespread (and sometimes recommended) use of the InterCap style, where all component words are concatenated with no intervening spaces, and each word-initial letter is capitalized (e.g., MilkProduct, growsIn), this style will be discouraged. Instead, the dictionary citation form is recommended here, with spaces being replaced by underscores, e.g., milk_product. The reason for this is (1) the latter style accommodates other languages (e.g., Chinese, Arabic) whereas the InterCap style is specific to European alphabetic languages and (2) the correct forms of the words making up a given term can be more easily recovered for later processing.
Number
See the rule for thesauri.
Special characters
Remove hyphens, e.g., post-Modernism should be rewritten as postModernism. Replace & and / with And. For all other non-alphanumeric characters, replace with the html code for the character (stripped of non-alphanumeric characters), and delimit with periods, e.g., ' becomes apos, and Sam's becomes Sam.apos.s.
Properties
Properties link two concepts together. We distinguish two types of properties in our ontologies: data properties and object properties.
A data property is a concept whose value consists of a literal. The name of a data property should occur in the singular, e.g., colour, age, temperature.
An object property is a concept whose value is another concept. One awkwardness that arises in attempting to name object properties using suggested conventions is the use of the present tense form of a verb, e.g., grows_in, eats. The problem is that the truth of the resulting proposition, e.g., may not necessarily be valid in the present, but in the past or for a given time period. Modality (indicating e.g., possibility, necessity) and verbal aspect (the distribution of the action across time) are also not expressed using the present tense convention. As a start to circumventing these problems, a property is added to the relation to create the possibility of specifying temporality (could be enumerated values, past, present, future, or more refined), e.g., PlantB afflictedBy - [past] PestB. By default, the value should be present.
When naming static properties, auxiliary verbs like is or has, should be omitted, e.g., partOf, ingredient.
