OpenBOM Core Data Model: Objects, Properties, Links

In my recent article, OpenBOM Data Model (2025 Update): A High-Level Overview, I introduced the foundations of the OpenBOM Data Model and shared how it continues to evolve to support modern product development and manufacturing. That overview highlighted the five main pillars of OpenBOM’s flexible, graph-driven approach: the Core Data Model, the Reference–Instance structure, Design Projects, Procurement and Inventory integration, and Custom Extensions.

Today, I’d like to go deeper into the Core Data Model itself. This is the foundational layer of OpenBOM. It defines how product data is represented, structured, and connected, ensuring that every other capability—from BOM management to procurement planning—can build on a robust and flexible base.

The Core Data Model consists of five main elements:

1. Data Objects
2. Basic Properties
3. References & Object References
4. File Properties
5. Views (User and Team Views)

Let’s unpack each of these in detail.

Data Objects: The Building Blocks

At the heart of OpenBOM are Data Objects. These are the primary entities that represent the things you want to manage—whether that’s an item, a bill of materials (BOM), a catalog, or a design project.

Think of them as the digital building blocks of your product. An “item” might be a resistor, a gear, or a purchased assembly. A BOM represents how those items come together. A catalog stores reusable definitions of components, while projects organize and connect all related product data.

By modeling product information through these objects, OpenBOM creates a consistent structure that works across engineering, manufacturing, and procurement. The flexibility of data objects means the system can scale from a single engineer tracking parts in a project to an entire enterprise coordinating multiple product lines.

Basic Properties: Defining Attributes

Every object in OpenBOM is described by its properties. These properties capture the details that define an item or record.

OpenBOM supports a wide range of property types, including:

• Text (e.g., part name, description)
• Numeric (e.g., weight, length, tolerance)
• Date (e.g., release date, approval date)
• Currency (e.g., unit cost, total cost)
• List (drop-down options for standardized values)
• Multi-select list (for selecting multiple applicable values)

These fields serve as the descriptors of your product data. For example:

• A resistor might have a part number, resistance value, tolerance, and supplier.
• A machined part might carry revision level, material type, and unit cost.
• A BOM might include properties such as total estimated cost or assembly revision.

One of the most important aspects of OpenBOM’s approach is flexibility. Instead of forcing you into rigid, pre-defined schemas, OpenBOM allows you to define and manage custom attribute sets that match your business needs.

That flexibility means you can model your products in a way that aligns with your industry, your processes, and your company standards—whether you’re building electronics, medical devices, industrial equipment, or consumer products.

References & Object References: Connecting the Dots

In modern product development, no object exists in isolation. A part might be linked to its datasheet, a supplier record, or a compliance document. A BOM might need to reference a regulatory requirement. This is where References and Object References come in.

• Reference (simple link): This is the simplest form of connection. A reference property lets you store a label and a URL. It could point to an external website, a document viewer, or another application. For example, you might add a reference to link an electronic component directly to its datasheet on a supplier’s website.
  
• Object Reference: This is a more advanced link that connects one OpenBOM object to another specific object inside the system. Unlike a simple URL, an Object Reference leverages a projected attribute—meaning you can choose which property of the linked object is displayed.
  
  For example, an item could reference a manufacturer object, showing the manufacturer’s name as the projected attribute. Or an item could link to a requirement object, displaying its requirement ID or description.
  

The value of these references is that they create a connected data model. Instead of duplicating information across multiple places, OpenBOM maintains a single source of truth and builds relationships between objects. This connectivity ensures data is consistent, reduces errors, and strengthens the digital thread that ties your product lifecycle together.

File Properties: Managing Design Artifacts

While references and object references connect to links and data objects, File Properties connect to files themselves.

A File Property works much like a reference—but instead of pointing to an external URL, it points to a file stored in OpenBOM’s secure cloud storage. This means you can attach and manage any type of file—CAD models, drawings, specifications, PDFs, spreadsheets, or even images—directly within the Core Data Model.

Each file property stores not only the file itself but also metadata about the file. For CAD files, this might include file type, last modified date, or version. For documents, it could include author, revision, or approval status.

Files are linked to data objects (items, BOMs, or projects), ensuring that product records are not just abstract entries but also carry the actual design and supporting documentation.

OpenBOM also provides version control and traceability for file properties. Every update is tracked, previous versions are preserved, and a complete history is available. This means teams can always return to earlier states of a design or document—improving compliance and reducing costly mistakes.

Views: Making Data Usable

Finally, OpenBOM’s Core Data Model includes the concept of Views—configurable perspectives on the same underlying data.

Different teams need different information. An engineer may want to see part number, revision, and material type. A procurement specialist may care more about cost, supplier, and lead time. With Views, each role can access the same object but see only the properties that are most relevant to them.

OpenBOM supports both user views (individual configurations) and team views (shared perspectives). This makes it easy for companies to standardize how different roles work with data while still giving individuals the flexibility to tailor their experience.

By enabling multiple perspectives on the same data, Views improve collaboration, reduce confusion, and ensure everyone is aligned without overwhelming users with unnecessary details.

Conclusion: Why the Core Model Matters

The Core Data Model is the foundation of everything OpenBOM does. By defining objects, properties, references, files, and views, it provides a powerful yet flexible framework for capturing, organizing, and connecting product data.

This model makes OpenBOM more than just a tool for managing spreadsheets or files—it makes it a true digital backbone that can adapt to the diverse and changing needs of modern manufacturing.

In the next article, we’ll continue this journey by exploring other elements of OpenBOM’s flexible  data model such as Reference–Instance structure, xBOM, procurement, and custom object extensions. Stay tuned, this is where things get even more exciting.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg