An infrastructure project in Ireland required installation of new power and communications cables. Running of these new cables necessitated works for new and existing ducts and chambers. Historically, as-built records from such projects would comprise documents in unstructured data formats (e.g., PDF, CAD). However, the client, a major public asset owner, sought to collate structured asset information that could be used for improving future decision making. The client did not have an overarching data strategy at the outset of the project. Further, the client did not have an asset information management system (AIMS) for duct, chamber and cable asset information. As such, the presenters proposed a vendor-neutral, standards-based approach to asset information management, with machine-readable rules and instance data using LD/SW technologies. This approach was intended to futureproof the data such that it could be consumed by any adopted AIMS. Further, demonstration of the approach itself was intended to inform the stakeholders of the potential benefits and disbenefits of its adoption across other areas of the asset network or other asset types. A systematic approach was followed throughout. Clearly defined use cases were elicited from end users such as maintainers and operators. A sub-set of these use cases was selected to inform information needed for each asset type. Rather than trying to model all 'nice-to-have' information, a minimum viable product approach was taken, retaining focus on the most important information and functionality. A top-level ontology was developed, based on a draft version of EN 17632-1. A 'chambers, ducts and cables' ontology was created. A small set of instance data was loaded into a triple store along with the ontologies, and test queries were run to ascertain if the agreed use cases were met. This resulted in some refinement of the ontologies prior to extending instance data collection to the whole project. The ontologies formed the basis for configuration of a proprietary site inspection mobile application, used to gather data such as location, duct orientation, and photographs. Asset data was supplemented through desktop study of as-built records. The data was then exported in JSON format, post-processed using Python, and then converted into RDF. SHACL validation was run on the dataset to confirm compliance with the ontologies and with W3C standards prior to upload to the triple store. The adopted triple store presented query results in XML, tabular, image, or map formats, and facilitated GeoSPARQL. The agreed use cases were achieved and demonstrated to the client. The work presented various challenges, including: a) limited functionality of popular CAD, GIS and AIMS software for reading or writing RDF; b) complexity of managing information about below-ground assets; c) multi-step post-processing of collected data; and d) communicating the outcomes in the absence of a user-friendly interface for interrogating the data. (Development of such an interface was outside the project scope.) However, the prospective benefits of a modular, scalable, standards-based, machine-readable approach are clear, and they warrant due attention by public asset owners seeking to futureproof their data and systems.