(future enhancement: instead of hard-wired property key value, show an even localisable custom UI string) for properties of type number, auto-generate the next value whether a property must, can or may not carry a language flag. Applies only to concept properties if true, then this property's value may only who up once amongst its siblings a multiselect picklist-like data structure to flag a property with a set of values a default value to use when adding the property a custom property, such as Definition of Part-of-Speech as configured in the Model supports markdown main structure to carry data about a concept: properties/assets + terms supports markdown can be any string to identify the concept, term, property, edge outside of Coreon - during import it gets its unique cuid unique, persistent identifier "group" or "normal" - if group then UI renders the concept as a group concept if true then UI renders all its sub-tree concepts as part of that branch a concept-like node that acts like a placeholder and points to a referent concept main type to carry relational information: reference to a source and target concept + the type, i.e. the name of the relation can be any string for custom associative relations. Built-in are the following for hierarchical: SUPERCONCEPT_OF, HAS_SPECIFIC, HAS_PART, HAS_INSTANCE The Coreon XML root node import policies. If given the policy in the file overrules all other given policies All settings a repository is configured with (properties, languages, rating rules ...) properties for concepts properties for terms (future enhancement, no effect yet) one or more rules whether a term should be treated as preferred or undesirable, depending from the value of a given term property additional breadcrump-like computation of a hierarchical path of a given property key associative relations (hierarchical ones are built in) user roles for access management (deprecated, not in use by Coreon) all concepts and aliases all relations history log when not saved inline