Definitions and a Map

A taxonomy is a formal classification system that consists of nodes and the nodes associated list of attributes. At the highest level, the top node is called the domain. If the classification system has nodes that are secondary or tertiary to the domain node, then the secondary nodes are branch nodes and the tertiary or terminal node is called a leaf node. From here, further searching will require the interrogation of the database with parametric content. Parametric content is the values or text strings associated with each attribute, and again, all nodes have some list of attributes.

Content consists of a hierarchy of added-value additions starting with data. Data is the lowest form of content and consists of numbers and text strings.

What is a Taxonomy?

In general terms, a taxonomy is a rule set that demonstrates how to organize and classify a portion of the world. Specifically for electronic components, a taxonomy is a hierarchical classification scheme for organizing electronic component information accompanied by binning logic, a thesaurus, and a lexicon.

A taxonomy is incomplete unless it is accompanied by the following components to assist in the search and finding of an electronic component:

• Binning logic—describes what the rules are for placing electronic devices into a leaf node. Typically needs to be visible in a text window.
• Thesaurus—equivalent terms used to describe a leaf node or attribute. Should be available in a help file or located within mouse-over support.
• Lexicon—a dictionary of terms used, which is usually available in a help file.

How Is a Taxonomy Constructed?

A taxonomy architecturally is a series of domains, each with its own branch nodes and leaf nodes. A domain contains a cluster, group, a collection of parts that all share a few common foundation attributes, characteristics, parameters. Branch nodes share the foundation attributes from the domain, but further divide the domain into groups that share additional common attributes. Leaf nodes share foundation and common attributes plus additional unique core attributes—attributes that are not shared by any other leaf nodes in any branch within a domain or in another domain.

Inheritance is the mechanism of sharing attributes as the search flows down the taxonomy to the end leaf node. When leaf node attributes are displayed, attributes from its branch and domain are aggregated and displayed together.

Why Use a Taxonomy?

• It is a useful search tool when trying to find a family of products with the same attributes without knowing the manufacturer or part number.
• A taxonomy allows users to locate components by looking for them in a predictable and well-defined "bin".
• Enables apples-to-apples comparisons between like component families without knowledge of a part number or manufacturer.
• A taxonomy always returns results. Keyword search or selected parameter values may not return results; no results may be a consequence of no parts in the database or poorly chosen keywords or parameter values.
• A taxonomy with inheritance enables large, medium, or fine grain search "net" with results every time.

What are the Issues of a Flat Leaf Node Structure?

• A flat leaf node structure side steps the issue of a standard taxonomy completely. All organizations have different opinions of taxonomy construction. Rather than standardizing on one taxonomy, a flat leaf node structure avoids the inherent conflict. As a consequence, the end-user will have to reconstruct a taxonomy manually if it is required.
• Leaf node attribute parametric content is all that is required when searching for parametric values. The implication is that the part number and manufacturer are already known. Purchasing agents, component engineers, and design engineers that already know the part number do not need a taxonomy for search support if all the information returned is parametric values.
• If the part number and manufacturer are not known, searching by parametric value or keywords will find no match in a majority of searches even if a part is available. Most current built-in search engines are not intelligent. And the more parametric values added, the smaller the probability will be in finding an electronic component.

How to Use a Taxonomy and Parametric Search Together

If the manufacturer or part number are not known, the search—actually the find—process starts first with a taxonomy search traversing down to a leaf node to find a family of products. Then a core attribute search follows at the leaf node level to narrow a family of products down to a few potential parts within a family of products by inputting values into the core attribute fields. (The core parameter values are a minimum set of parametric values that a design engineer needs to select to pick a family of products as candidates for a particular design.) The designer then would download a datasheet for more design information detail once a part number and manufacturer are known.

Rules to Build a Taxonomy

When building a taxonomy, the following general rules should apply to all domains, branch nodes, and leaf nodes:

• Expose and promote branch nodes or leaf nodes based on how a designer selects devices if a leaf node has too many devices placed into it.
• Build a taxonomy to support placement of a device into only one leaf node recognizing that some electronic component engineers or marketing personnel might place a device into two leaf nodes. Clearly identify binning logic (detailed descriptions) for placing devices into leaf nodes.
• Create separate application-specific/standards-driven leaf nodes only if the devices fit into a single application/standard and users know that application or the standard's name.
• Build a leaf node based on its features, not its parameters. Create new leaf nodes when a leaf node grows larger than other similar leaf nodes in a domain.

Rules to Use When Promoting a Leaf Node

• Only promote when several device families in the target leaf node can be found (use a loose rule of thumb here).
• Promote when only one or two attributes are different compared to another leaf node in the same branch node (use a loose rule of thumb here also).

Rules to Use When Creating a Leaf Node from a Branch Node

• Make sure that the new leaf node inherits all attributes from branch nodes above it and has additional unique attributes
• Demote the parts into a new leaf node when too many parts in the old leaf node exist
• End users wish to use taxonomy searches to find well-known trade name based devices within a branch node; these added leaf nodes can have no new attributes unique to themselves, but provide a quick way to get to trade name devices (this is the only exception to leaf node being created without a unique attribute)

Rules to Use When Breaking Out New Leaf Nodes

• Use a well-known trade name as a leaf node.
• Use a military specification as a leaf node.
• Use an IEEE specification as a leaf node.
• Divide the branch node by building leaf nodes with the most popular core attribute used to select the components found in the old leaf node.
• Create at least two leaf nodes.

Binning Rules (Placing Components into a Taxonomy)

• Place the electronic component into only one leaf node; viewing will support multiple associations based on user needs.
• Try to avoid the "other" bin; garbage collection is for waste management, not databases; use only as absolutely the last chance to place a part into a branch node.
• Place ASSP devices into branches where the device is uniquely used even if the part has a CPU or DSP core; embedded software converts the general purpose nature of the device into a part that is unique and can only be used in a single application.

General Attribute Rules

• All attributes are inherited; attribute inheritance starts at the root level where all electronic components share these attributes.
• Use only those attributes that a designer would use to select a device family datasheet (this is a core attribute definition).
• Do not use design related attributes as leaf node attributes (part of the logical inversion to the core attribute definition).
• Include test conditions for those attributes that are specified differently across multiple manufacturers.
• Attributes should not be chosen to select a single part—this would entail additing all attributes from a datasheet; focus on core attributes only.
• Include production attributes for QA/QC tracing—author, date, parameter extraction date, production revision number, etc.
• Include manufacturer ID based on DUNS numbering.
• Include symbols and footprints; footprint attributes should include package type, package width, and pin spacing.
• Place common attributes shared by leaf node members at the next highest branch node.
• Tolerance should not be used; some tolerances are asymmetrical; therefore, use published or derived minimum and maximum.
• Include part number information for generic part number, orderable part number, UPN (universal part number), GTIN, and UN/SPSC support.
• Include shipping information attribute only when shipping information is encoded into the orderable part number.
• Use only upper case letters for attribute naming.
• Use only well known acronym/abbreviations for leaf node naming; SCR, ATM, F/F, etc.
• Provide marketing input attributes (keywords, part description which includes the title of the datasheet, market segment, etc.)
• Provide collateral type support including collateral type (manual, datasheet, etc., collateral URL, etc.).

Parametric Entry Rules

• Conversion from tolerance to min/max is the only normalization allowed; interpolation for parametric value normalization if forbidden.
• Graph-based values are not allowed; only numbers found in the AC and DC specification area are allowed when performing parametric extraction.
• Use the worst-case maximum parameter number and include its test conditions for all parameters that do not specify maximum.
• Use standards as an attribute for telecom, datacom, and wireless devices.
• Try not to use *, -, & or any other non-alphanumeric character; this will play havoc with EDA tools and database operation unless special provisions are invoked within the software to handle these special characters.