IFC-LD

"Container" is the root element within the IFC-LD type hierarchy. All assets exchanged via IFC-LD are derived from Container. Containers defines several key properties:

A Component is a Container that holds "contents", captured at a specific time, declared by a specific stakeholder. A Component’s "contents" can represent a property value, a reference to an Entity, or some other capability defined by other specifications.

Here are example Components in IFC-LD:

Components should be related to the Entities they qualify through the "componentof" property. A Component may be the componentof more than one Entity. When seen from the point of view of an Entity, Components describe qualifying aspects of that Entity.

Component data is stored in its "contents". The structure of contents depends on the Component. For Entity references, contents provides the @id of the targeted Entity. For property values, "contents" is made up of a "@type" and "value", the latter of which may be a (possibly nested) list.

Components may also declare a "shortcut" property, whose value is a URI, specifying the relationship the Component defines between its linked Entities (via componentof) and its contents. For example, a Component may declare its linked Entity is related to its Entity reference contents via Building Topology Ontology's "hasElement" relation:

Linked data-aware systems may then use this shortcut property to "unpack" the underlying RDF triple:

Use of Component shortcuts is optional.

"Entities" are a Container for Components, with each Component encoding some qualifying aspect of the Entity. Like Components, Entities are addressed by URI. Entities typically capture any asset, real or imagined, stakeholders want to track across time and revisions. Because their state is the superposition of many Components (each with its own provenance information), Entities do not not themselves declare provenance information like timestamp or ownership.

Entities should be grouped into one or more Packages, each of which captures the circumstances that changed the state of the Entity (through the introduction of new Components). An Entity may be the entityof more than one Package.

Here is an example Entity:

Packages are Containers for Entities. Packages define some event - a project deliverable, point-to-point exchange, etc - that justified the modification or transaction of Entities and Components. Because Packages describe events, they contain provenance information similar to Components.

Here is an example Package:

The IFC-LD "Stream" format, identified by media type application/ifc.json+stream, captures all IFC-LD assets in a flat array. Here is a sample IFC-LD stream:

IFC-LD streams are useful for event-driven systems and one-at-a-time processing. They encourage the the exchange of "delta updates", wherein individual Components, Entities, and Packages can be exchanged, instead of monolithic model files.

The IFC-LD "Package" format, identified by media type application/ifc.json+pkg, captures IFC-LD assets as a nested hierarchy of Containers, where a root Package contains Entities, and Entities contain Components.

Here is a sample IFC-LD Package file:

The IFC-LD Package format is most useful for browsing the Entities of a single Package. Because Entities and Components in this format are indexed by JSON keys, systems without linked data support can still traverse the network of linked Entities by dereferencing the corresponding JSON keys.

application/ifc.json+stream and application/ifc.json+pkg are losslessly interoperable. A IFC-LD stream can be encoded in the package format and back again with no loss of information. The Proof-of-Concept Transformation Pipeline outlines a reference architecture for this transformation flow, with notes for future work.

Future versions of the IFC-LD specification may introduce at least one JSON serialization that is derived from, but not losslessly convertible to, the stream or package formats. These serializations would be tailored to specific use cases (e.g., visualization) where small file size is the key Entityive.

To help take IFC in new directions, we recommend the compositional modeling support of IFC-LD be used to develop collections related of Component definitions, called "Modules", that fulfill specific use cases, design processes, or functional categories. We imagine modules tailored to energy performance, massing design, construction administration, and more. Industry working groups for each module would take responsibility for the module’s design and release cycle. Many modules would be publicly shared to increase interoperability, but some may be tailored to particular delivery processes or firms. All Modules should supply a standard set of Component schema definitions (see Schema Validation Strategy).

Yes. Consider the following P21 instance:

You could encode this in JSON as

It captures most of what’s in the original instance:

It’s a nice encoding. It also has multiple problems:

What changes would need to be made to the encoding to fix this?

Fixing these problems resolves to something that looks very much like IFC-LD. We end up with a format that is largely self-describing. This inherently increases the data’s size, but in trade reduces the burden on consuming systems, because the data itself will describe how it should be consumed. We suggest the value of self-describing, integrable data outweighs the storage overhead, especially given the need and complexity of common coordination models within the design and construction industries.

JSON Schema is primarily useful for validating the syntactic structure of JSON documents. It can ensure a JSON document has a specific set of field names, arrays of a certain size, or numeric values within a particular range. It is challenged, however, to define constraint rules that are deeply relational (graph-like), or to handle constraint checking when the input data can come in different "shapes". Unfortunately, both of these qualities are core to the structure of IFC-LD.

SHACL avoids JSON Schema’s limitations here because it defines a graph-based constraint language that’s independent of the serialization. It allows complex constraint definitions that traverse multiple Entities, or members of a specific class of Entities, and works no matter how the data is encoded - XML, JSON-LD, Turtle, etc. This does make the schema definition language more complex, but many industry rulesets inherently require this complexity for validation.

SHACL is the default recommended schema language for IFC-LD simply because it provides the greatest flexibility to the widest number of stakeholders. The heuristic to apply SHACL shape definitions to IFC-LD Components intends to simplify and standardize the schema extension workflow.

The use of SHACL does not preclude the use of JSON Schema for validating specific parts of IFC-LD. In fact, the OpenAPI Specification depends on JSON Schema to check the structure of Packages, Entitys, and Components. Users are encouraged to expand these validation definitions for their use cases as needed.

Legacy IFC Components have URIs that are based on an attribute’s offset within a P21 instance, rather than its name in the corresponding EXPRESS schema. For example, the type of the fourth attribute of an IFC4 Person is identified by the curie ifc4:person/4, rather than ifc4:person/middlename. Tying the URI to the attribute name requires any translation pipeline somehow be aware of the schema the instances model, because P21 files do not include attribute name information. The Proof-of-Concept Transformation Pipeline does this through a data enrichment step. Should the schema version not be known to the pipeline, or no enrichment data be available, a translation pipeline would have no way to know how to encode the attribute type URI. Identifying the attribute URI by offset, which is guaranteed to be known, ensures graceful degradation in the event an unknown schema is encountered. As a side effect, it means IFC-LD technically works with all P21 files, even those unrelated to IFC.

IFC-LD is Like ifcOWL in that it is:

IFC-ID differs from ifcOWL in that it does not:

IFC-LD tries to package the power of linked data in a framework that’s approachable, intuitive, and open-ended.

There’s been exciting work on purpose-built industry linked data models over the last few years. Each of these model can be seen as a "module" describing one aspect of industry processes or structures. Being based on linked data, these modules are composable, but resolution of the resulting data is low-level: everything is a collection of (subject, predicate, Entity) triples. We believe this resolution is too granular for most industry use cases, especially those without linked data support. IFC-LD provides a more Entity-oriented definition of what a module is and allows any of those purpose-built data models to be plugged in as needed (e.g., via a Component’s shortcut). By analogy with electricity, IFC-LD defines the shape of a standard data socket, so anything fitting that socket can plug in. IFC-LD is effectively an higher-level abstraction and composition layer on top of these other models.