OTL implementation that holds up at the first data drop

An object type library, usually shortened to OTL, is the agreed list of every kind of object an asset owner manages, together with what must be known about each one. You will also hear it called a reference data library, an ontology, or in the Netherlands an objectenbibliotheek. The names differ, the job is the same.

Each object type in the library carries three things. A clear definition, so a transformer means the same thing to the engineer, the contractor and the maintenance system. A set of properties, such as rating, material or installation date, with the unit or value list that is allowed. And relations, which say how objects connect: what an asset is part of, where it sits and who supplied it.

A dictionary helps people agree on words. An OTL does that too, but it is also written so that software can read it. That is what makes it useful beyond a single project. The OTL is the asset owner's structured catalogue: it defines which classes of assets exist in a programme, what attributes each class carries, how object types relate to each other, and which documents each type requires.

The concept emerged from Dutch infrastructure practice in the 2000s, driven by large grid operators and public infrastructure agencies who needed a shared language for data exchange across hundreds of contractors and suppliers. The Netherlands brought it into the NEN 2660 standard series, which provides an ontology for the built environment and a formal basis for linked-data asset management. It has since spread across major infrastructure programmes throughout Europe.

The delivery format for OTL-compliant asset data is typically an ICDD container, defined in ISO 21597. An ICDD package is a structured ZIP archive containing documents, linked data payloads and the index that ties them together. It is machine-readable, version-controlled and auditable, which is exactly why asset owners have moved towards it and away from spreadsheets.

The OTL sits on top of the reference designation system. Assets need consistent identifiers before their attributes can be linked to the right object types. This is why OTL work always connects back to how you designate your assets: RDS-PP, IEC/ISO 81346 or the owner's own designation specification. Without that foundation, OTL mapping produces data that cannot be reliably traced to a physical asset. We cover that foundation in our article on why asset registers and document registers disagree and in our piece on reference designation services.

Most asset owners run a mix of tools: BIM and CAD for design, GIS for location, an asset register or CMDB for operations, and a document management system holding everything else. Each tool stores data its own way, and every contractor brings its own naming habits. The same pump ends up described five different ways in five places.

An OTL fixes the reference point. Once types, properties and relations are agreed centrally, contractors deliver against that standard, systems can exchange data without manual translation, and the owner can link its data to external sources such as norms, product catalogues and public registers. It also reduces vendor lock-in, because the meaning of the data no longer lives inside one software package.

The asset data standard the OTL creates is also what makes a digital twin useful rather than decorative. A twin that cannot reliably answer which component belongs to which system, or what its rated capacity is, is not an operational tool. The OTL gives it that grounding.