This is an archive of an inactive wiki and cannot be modified.

This proposal was discussed at the 2007-09-11 telecon, and subsequent substantive changes are to be added as proposed amendments for a later discussion.

The page BLD Name Issues contains ideas for how to name various concepts in BLD, taking these naming conventions into account.

Motivation

Naming conventions, once adopted, help people converge on a shared vocabulary and then make it easier to use the terms in that vocabulary. By constraining the space of possible names and the possible interpretations of the names, the conventions make it easier to figure out what a name means and make it more likely that one will guess a name correctly. Although it is tempting for experts to develop and use a jargon for their sub-field (in this case a RIF dialect), to support extensibility it is important that dialect developers use terms which will be correctly understood in the broader social context of the technical domains related to RIF, including the Semantic Web, Logic, Software Development, and Business Rules.

The dialects which are most heavily reused (eg BLD) are likely to have the smalled number of names but be used in the largest number of RIF documents, so the naming decisions made in such documents are the most important.

Scope

The following conventions are for naming syntactic classes and properties (or roles) in the RIF abstract syntax, which uses strictly alternating class/property tags, i.e. is "fully striped". This affects the XML syntax. The names selected for the abstract syntax do not necessarily affect the presentation syntax, although they are used in writing down the grammar of the presentation syntax.

Sources

The conventions here reflect our understanding of industry consensus where there is one, but some of the conventions are more arbitrary because we found no consensus. We considered the [http://www.ibm.com/developerworks/library/ws-tip-namingconv.html Java naming conventions].

Uppercase / Lowercase

  1. The names of classes and properties should be words or phrases in mixed case (CamelCase), with the first letter of each internal word capitalized, as in Java.

  2. If a sequence of words is combined into one word, which is in common use (such as "ruleset"), it should be treated as one word (without capitalizing the "s"). (SandroHawke: Maybe not. Maybe the opposite convention would be better.)

  3. The first letter of class names should be capitalized.
  4. The first letter of property names should not be capitalized

Abbreviations

  1. Whole words should be used, unless the abbreviation is more popular and better-understood than the full form (as with "XML", "Combo", or "Turboprop").

Proposed Amendment, from concerns voiced in 2007-09-11 telecon, by SandroHawke: If, without external explanation, an abbreviated term is no more confusing or misleading than a longer term (to the target audience), then it may be used.

Proposed Amendment, from reading some other naming conventions, SandroHawke: Names should genenerally be less than 15 characters. If they are longer than this, more effort should be invested in finding suitable names.

Natural Language Grammatical Issues

  1. Class names should be nouns or noun phrases.
  2. Class names should fit roughly (not necessarily with perfect grammar) into a sentence like, "Every member of this class is a(n) <class name>".

  3. Property names should be nouns or noun phrases.
  4. Property names should be singular, even if the max cardinality is greater than one, except that list-valued properties MAY have plural names.
  5. Property names should be suitable as labels on a form.
  6. Property names should be suitable as column headers on a table.
  7. Property names should fit roughly (not necessarily with perfect grammar) into a sentence like "<instance> has <property name> <value>" and "<value> is a <property name> of <instance>."

Proposed Amendment from DaveReynolds: If the direction of the property is unclear, then adding words like "has" and "of" to the ends of the property names is allowed. Example, from skos, is "broader", where the name "broaderThan" helps clarify the direction.

Proposed Amendment from HaroldBoley: Natural language grammars (e.g., the English grammar), under the perspective of internationalization efforts, can provide additional conventions. However, in a logic context, natural language categories are overlapping, and conventions derived from them can act as suggestions only, since other criteria, such as established name use in the broader social context of all of RIF, should have higher priority. As such, the restriction of class names and property names to be nouns or noun phrases is too strong and should be removed. Class names like "Exists", "And", and "Forall" are good, for instance.

Proposed Amendment from SandroHawke: Add: Although class and property names should be understood as nouns or noun phrases, sometimes words can be omitted from the noun phrase (usually in the interest of brevity) or new terms can be coined without significantly reducing the clarity. These new terms become nouns or noun phrases in the jargon or technical language around the given vocabulary. For example, there is no short and clear name for the class of logical formulas which begin with an existential quantifier. (FormulaWhichBeginsWithExistentialQuantifier is quite clumsy, as is ExistentiallyQuantifiedFormula.) It is acceptable to call such this class "Exists", even though "exists" is a verb, with the understanding that "Exists" becomes a noun in the jargon and one can gramatically say, "I'm not sure if that's an exists or some other kind of formula." In general, adjectives can be turned into nouns most easily, because they are understood as modifying some implied noun, so "existential" might make the transition easier, as in, "I'm not sure if that's an existential or some other kind of formula."