Components

Components are one of the two base entities in the database (the other being actions). A component is defined as one of the following:

• a single physical object (for example, a geometry board)
• a group or assembly of physical objects that can itself be considered as a singular entity (for example, a shipment of geometry boards, or a fully assembled APA). The objects making up the group or assembly do not have to be identical, nor do they have to be single components already recorded in the database

Each individual component that is entered into the database has a corresponding 'component record', which is a JSON-formatted document containing all of the information relating to the component ... whether user-defined (via the component type form) or provided automatically by the database itself. Please see the Component Record Fields page of this Wiki for a full description of the possible information that a single component record may contain.

Identifiers

Full UUID
The primary identifier for any component is the full UUID - a 32 character alphanumeric string of the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (i.e. characters grouped into 8-4-4-4-12). A component's full UUID is generated automatically by the database when that component is first created, and immediately saved into the component record. The full UUID remains uniquely associated with the component regardless of any later editing of the component record (i.e. it is the same across all versions of a single component), and it cannot be changed after it has been generated and associated with the component.

The full UUID is designated as the primary component identifier because it is the only piece of information that is guaranteed to be available for, and unique to, each and every individual component in the database, regardless of component type and/or any user-defined information.

Short UUID
Another component identifier is the short UUID - a 20 to 22 character long alphanumeric string, which is translated directly from the full UUID described above. While this compactness might appear to make the short UUID more approachable, due to technical limitations with the software used for this translation, the reduced number of characters does mean that it cannot in principle be guaranteed that every full UUID will correspond to a unique short UUID and/or vice versa. That being said, the probability of a non-unique short UUID being generated from any given full UUID is extremely small, so short and full UUIDs can be taken as being uniquely paired for all practical purposes.

QR Code
To reduce the complexity of the database, the short UUID is never directly used - i.e. it cannot be searched for (unlike the full UUID), nor will it ever be displayed in the interface (although it is still viewable in the component record). Instead, the short UUID's only use is in a component's QR code. In a general sense, QR codes can be used to encode character strings in a compact visual format, and for this database specifically, the encoded character string is a URL that redirects to a particular component's information page (with part of this URL string being that component's short UUID).

Component QR codes may be printed out, laser-etched onto a surface, and/or otherwise made displayable, and any device which is both equipped with a camera and capable of running the database interface in a web browser can be used to scan a QR code, in order to display the corresponding component information page. The QR code scanning must be performed through the database interface, not through the device's native QR code scanning software. (This is because only the interface contains the bespoke software that is required to correctly decode the QR code, extract the short UUID, translate it back to a full UUID, and finally direct the user to the corresponding component information page.)

Other Identifiers
Depending on component type and/or user-defined information, certain components may have additional identifiers associated with them. For example, geometry boards can also be identified using their 'UKID' numbers, and each assembled APA has an associated 'DUNE PID'. Such component-specific identifiers should be created, assigned and formatted at the discretion of database managers and users, and the database development team will not attempt to control and/or otherwise dictate their usage (although we can of course offer guidance on the most efficient approaches to such identifiers).