What’s Inside an Object Type Library? Understanding OTL Contents and Scope

When you first hear the term Object Type Library (OTL), it might sound like a technical catalog or something buried deep in the domain of data specialists. But a well-defined OTL can make life easier for everyone who works with data, especially those designing, building, or maintaining complex systems.

From engineers and asset managers to software vendors and project teams, OTLs help ensure we all speak the same language. But what exactly goes into an OTL? And how do you decide what shouldn’t go in? That’s what this blog is about

First, What is an Object Type Library?

An Object Type Library (also called a Reference Data Library or RDL) is a standardized framework for defining the abstract types of things we work with. Think, for instance, about physical assets like bridges or activity types like inspections. These are not instances of objects, like this specific lamp post on Main Street, but rather the types of a lamp post.

An OTL describes what should be registered in software and what data should be exchanged between systems. It’s always tied to standards and created to support software-based data exchange, automation, and better collaboration.

Why Use an Object Type Library?

The main reason to use an OTL is clarity. When multiple organizations collaborate on a project, confusion can arise from differences in terminology, levels of detail, or data formats. OTLs help bridge those gaps by:

• Improving communication across teams
• Facilitating smooth data exchange
• Enabling model-based design and operations
• Supporting long-term asset lifecycle management

All of this hinges on how well the content of the OTL is designed and scoped.

The Contents of an Object Type Library

So, what should go into an OTL? Let’s break it down and use the concept ‘Physical Object’ * as an example:

1. Terms
These are the labels or names used in your domain, such as bridge, dike, wheel, and lamp post. Clear and agreed-upon terms are the building blocks of your OTL.

2. Definitions
Every term must be defined. What do you mean by a bridge in your context? Definitions ensure shared understanding and prevent ambiguity. A well-written definition also includes context and purpose.

3. Taxonomy
This is the classification structure that organizes your terms and definitions. For example: Structure → Bridge → Movable Bridge → Bascule Bridge. Taxonomies help users navigate the library and understand relationships between object types.

4. Aspects
Aspects describe relevant properties or characteristics of an object type. For a lamp post, aspects might include height, material, foundation type, or power source. These are often the attributes stored and exchanged in your software.

5. Parts
Some objects are composed of smaller parts. For example, a Bridge might include Support Structures, Deck, and Expansion Joints. Including these subcomponents helps structure data in a way that matches reality.

6. Links
An OTL can be linked to other libraries, external standards, or product catalogs. For instance, a lamp post type might reference a product from Manufacturer X. or be aligned with a maintenance classification like NEN 2767.

The Importance of Scope: Suitability and Balance

Defining the proper scope for your OTL is just as important as what you put in it.

Ask yourself:

• What is this OTL about? (e.g., Infrastructure? Buildings? Marine vessels?)
• What is it used for? (e.g., Design? Procurement? Maintenance?)

Without this clarity, it’s easy to end up with an OTL that’s too broad or too detailed. You can find a few examples below: 

• Too generic:
  An OTL for utility construction that only contains the term “office space” with no further breakdown.
  → Not helpful for designers or engineers who need more detail.
  
• Too detailed:
  An OTL for civil engineers that defines every possible screw type used in lamp posts.
  → More suitable for a product catalogue, not a general infrastructure library.
  
• Just right:
  An infrastructure OTL that lists common types of bridges (beam bridge, arch bridge, bascule bridge) and their key aspects.
  → Useful, reusable, and relevant across projects.
  

A Variety of OTLs for Different Purposes

There’s no single kind of OTL. OTLs always depend on the purpose, content, and audience. Some OTL types that you could use as examples are:

• A classification system (e.g., NL-SfB): A structured system that groups and categorizes types of objects or components based on shared characteristics or functions.
  
• An integration library (e.g., CB-NL): A standardized reference library designed to align data across systems and organizations, enabling consistent digital-process integration.
  
• A product catalog (e.g., Siemens): A collection of manufacturer-specific product types, often including technical specifications and identifiers for procurement and design.
  
• A maintenance standard (e.g., NEN 2767): A standardized framework that defines how to assess and describe asset condition and maintenance needs.
  
• A semantic dictionary (e.g., IFD Library for Building Smart): A shared vocabulary of concepts and terms, designed to support semantic interoperability in digital models.

Each type of Object Type Library serves a unique purpose, and each calls for its kind of content. The examples above are just a few of the many in use today. Curious to learn more or explore what fits your situation? Feel free to reach out to Rikkert van Riet.

Final Thoughts

The content of your Object Type Library should always align with your goals. Don’t try to capture everything at once; start with what your users need, and design a structure that can evolve with them. If you’re wondering where others often go wrong, we’ve outlined the most common pitfalls in this article.

At Laces, we believe the people working with the (OTL-related) data daily should play a central role in shaping how it’s defined and shared. That’s why our tools are built with collaboration and usability in mind, so your OTL becomes a living part of your workflow, not a barrier to it.

Interested in how an OTL could strengthen your data strategy? Get in touch today. We’re happy to share real-world examples or walk you through your first steps.

*Other concepts are: Functional Space, Matter, Agent, Activity, Function, Geometry, Document, State, Objective, Event, Risk, Aspect, Unit.