This Part 2 of the ICDD standard adds functionality to the container format specified in Part 1. Part 1 defines a generic container format to store documents using various formats and structure and the ability to provide links between documents or between referable subsets of these documents (documents and datasets are the payload of the container). Building on that foundation, Part 2 of this standard adds the possibility of adding more semantic (meaningful) information to the contents of the container, as well as to the links between pieces of information in the container using Linked Open Data technology. This standard does not prescribe the structure or format of the documents in the payload. This standard is suitable for industry sectors such as the built environment, where many different standards are used, where there is a mixture of digital representations of proposed or existing built and natural assets (in open or proprietary formats), requiring the use of legacy systems and the application of different classification systems. This part adds the ability to link, in a semantic and meaningful way, those islands of data represented using different formats and structure. This standard is not meant to replace other standards such as ISO 16739 which is recognized as the standard for describing building objects. This standard provides two conformance classes. Both conformance classes open the ability to specialize the container for use cases not otherwise handled. In Conformance Class A, the container format of Part 1 is expanded with an ontology dynamic semantics, providing basic support for creating an information model that captures the required semantics of project, organization or sector standards and agreements. By doing so, it provides building blocks that make it easier to link different sources of information. This is achieved by introducing support for typed entities, typed entity properties and typed relationships between those entities (such as the relationship between an assembly and its parts or between a physical entity and its associated requirements). There is also support for defining provenance, versioning and creating libraries. In Conformance Class B, the user is offered complete freedom to add user defined ontologies to the container, with the sole condition that it is expressed in RDF/OWL. The use cases are in line with those of Part 1, but may include numerous extensions. The following list gives some examples: 1. Make use of asset type libraries describing the required properties per asset type 2. Link to a specific classification system, e.g. CoClass, Uniclass or OmniClass"! 3. Add the ability for exchanging systems engineering information 4. Link to product requirement libraries 5. Add semantic links (i.e. meaningful links) to and between information provided using existing standards like PLCS, IFC and GML 6. Link to an ontology for Units and Measures, like QUDT 7. Link to one or more Product Catalogues Since this standard capitalizes on Linked Open Data technology, the header file, along with any additional RDF/OWL files, forms a suite that may be directly queried by software using standard techniques such as SPARQL.