The following provides rules and guidance for constructing property definitions.
All properties must have a definition.
Definitions are meant to be human-readable.
Definitions should provide more information than the terms in the property’s name, when possible.
In some cases, a property name may be so obvious (e.g.,
PersonHairColorText) that attempts to provide synonyms or alternate phrasing would be counterproductive. A definition does not have to be elaborate if the property name would be obvious to the general public.
Each data component definition must be unique from all others and distinguishable in meaning. No two definitions can be identical in wording or so close in meaning that they could refer to the same data component.
There is an exception for a property with multiple representations, like various substitutions of an abstract property. Since each substitution represents the same concept, they may each share the same definition.
Definitions of a part do not need to redefine the whole.
Definitions for elements like
nc:PersonHairColorText,nc:PersonName, andnc:PersonAgeMeasuredo not need to each define what a person is. That should be defined once by elementnc:Person.
Type information should not appear in a property definition
A property definition is intended to describe semantic meaning only and should be decoupled from specific representation or structure. The representation term of a property and the standard opening phrase of a definition provide enough context to determine if a property is a string, a date, an ID, etc.
More specific typing information usually belongs with the types (the structures) rather than the properties (the concepts). Things like patterns, code values, and the number of characters should usually not be embedded in property definitions.
There may be a few cases where providing such information is essential to the semantics of the property. In this case, it is permitted.
Definitions of properties with simple content or designated types should use a standard opening phrase as defined by the NDR. See the Reference Table for more.
Property definitions almost always begin with an indefinite article (i.e., “a” or “an”), never a definite article (i.e., “the”). This is based on ISO 11179 guidance.
Definitions must follow 11179-4 requirements, and should follow its recommendations.
| Rule | Applicability | Title |
|---|---|---|
| NDR 11-23 | REF, EXT | Data definition does not introduce ambiguity |
| NDR 11-24 | REF, EXT | Object class has only one meaning |
| NDR 11-25 | REF, EXT | Data definition of a part does not redefine the whole |
| NDR 11-26 | REF, EXT | Do not leak representation into data definition |
| NDR 11-27 | REF, EXT | Data definition follows 11179-4 requirements |
| NDR 11-28 | REF, EXT | Data definition follows 11179-4 recommendations |
| NDR 11-34 | REF, EXT | Standard opening phrase for date element or attribute data definition |
| NDR 11-35 | REF, EXT | Standard opening phrase for quantity element or attribute data definition |
| NDR 11-36 | REF, EXT | Standard opening phrase for picture element or attribute data definition |
| NDR 11-37 | REF, EXT | Standard opening phrase for indicator element or attribute data definition |
| NDR 11-38 | REF, EXT | Standard opening phrase for identification element or attribute data definition |
| NDR 11-39 | REF, EXT | Standard opening phrase for name element or attribute data definition |
| NDR 11-40 | REF, EXT | Standard opening phrase for element or attribute data definition |