qdb data rules
The Qualifier database (Qdb) is a standardized reference
database to facilitate the management and exchange of information. The
structure of the database ensures a high level of referential integrity and
As an impartial and industry‐sponsored arbiter of data, the role of the Qdb is not to provide
specific content, but it does standardize, and therefore clarify, the
description of the vehicle which is the subject of the data content being
exchanged. A standard reference table allows for faster and less costly
integration of data content from multiple sources.
following rules are used to control the inclusion of listings in the Qdb. These
rules should be followed when submitting changes to the Qdb through
Title Case: The first letter of each word should be capitalized. All upper
case qualifiers are not acceptable.
2. Uniqueness: No
Duplicates. Do not allow duplicate qualifiers. Duplicates would include
qualifiers where the wording is similar, but the meaning is the same.
3. Abbreviations: Use
only approved abbreviations. A list of “industry approved” abbreviations will
be published. As a rule, abbreviations are limited to generally accepted
terminology where common use and need for brevity are obvious. Examples include
“cm” for centimeters and “GVW” for Gross Vehicle Weight. All other terminology
should be spelled out completely. OE specific abbreviations (ASR, E.E.C., RPO
Codes) should be defined in the qualifier as well as abbreviated in
4. VCdb Attributes: No
embedded VCdb Attributes. A vehicle attribute should not be included in the
qualifier expression (even if used with Except logic) except as noted below.
“(Exc. Manual Transmission w/Air Conditioning)” should be delivered as two
separate applications: (1) <TransmissionControlType
id=″5″>Automatic</TransmissionControlType>, and (2) <Qual
id=″18067″>Without Air Conditioning</Qual>. The one exception is if an
attribute is excepted in an installation instruction or product note.
“Valve Cover Set Not Included For CRX HF.” Otherwise, we would be forced to
write the application at a very low level (the Submodel in this case), and that
goes against the basic idea of delivering data at the highest level possible.
5. OE Terminology: Avoid
OE terminology used in place of vehicle attributes. OE specific terminology is
allowed, but not if it means the same thing as an existing vehicle attribute.
For example, use the AWD attribute instead of “4-Matic”.
6. Compound Expressions: Avoid
ANDed "compound" expressions. Break unrelated compound expressions
into separate qualifiers wherever possible. Closely related qualifiers may be
Example - “To
<p1 type=”date”/> & Serial # <p2 type=”id”/>, or “"<p1
type=”num”/> Blade, without Leads” are both acceptable). Expressions with
“Except Logic” may contain compound qualifiers (there may not be enough
information available to translate it to positive logic).
- “Except 14″ Wheels with Traction Control” is allowed.
Parenthetical information that further explains the qualifier may also be
included in an expression.
7. Compound Expressions: Compound
expressions with OR logic is allowed. Since two or more qualifiers on an
application are always interpreted to be joined by an AND, the only way to
indicate an OR condition is to break it up into multiple applications. This
separation may not be the best way to display the information and so compound
expression with OR conditions are allowed.
“Police or Taxi”, “Dual Rear Wheels or Heavy Duty Suspension”).
8. Positions: No
Positions. Qualifiers should not include position information. All positions
are coded in the Position tag, even if the valid position for a PartTerminology
(xml attribute: PartType) is unknown or un-researched (i.e. N/A, N/R, U/K).
9. Part Numbers: Avoid
Part Numbers. Where possible, qualifiers should not include part numbers. If
you must include a part number because it is important to mention a related
part for an application, make sure the related part also has its own
application, and create a “part” parameter for the part.
Example - “A
<p1 type=”part”/> adapter is required when replacing the widget.”
10. Parameters: Don't
over use parameters. Only use parameters for information that is truly variable
and generally application specific. (For example, don’t substitute a parameter
for the “1” in “1st Design”). Do not use a parameter if the value will never
change (in context with the rest of the qualifier).
11. Plurality: Avoid
over use of optional plural. Don't use optional plural on end of terms that
must be plural as used. (<p1 type=”num”> Degrees, not <p1
type=”num”> Degree(s) unless you expect “1” to be a possible value.)
12. Quoted Terms: Use
quoted terms consistently. Enclose stamping/markings or other identification
strings in quotes to distinguish them from abbreviations.
13. Quantities: Use
spelled out numbers for quantities in ten or less. “with Leaf Spring Type
Clutch with three Mounting Holes" instead of "with Leaf Spring Type
Clutch with (3) Mounting Holes".
14. Special Characters: Do
not include special characters above 128 ASCII including a degree mark,
plus/minus sign or registration mark.
Question? Please email firstname.lastname@example.org.