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 data validation.

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.

The 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 www.enhancedstandard.com.

Syntax rules

1.        Use 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 parenthesis.

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.

Example - “(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.

Example - “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 kept together.

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).

Example - “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.

Example - “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 technology@autocare.org.

  • Share