Complexities in the ifcOWL graphs
ifcOWL graphs are complex, mainly because the ifcOWL ontology directly reflects the IFC EXPRESS schema. As a result, ifcOWL graphs contain many of the data constructs that are included in the IFC EXPRESS schema as well. These complex data constructs are redundant for many use cases. Several of the more complex and not that informative data constructs are given in the below figures (sample files smallhouse.ifc, smallhouse.ttl, and smallhouse_simple.ttl).
Also, some parts of the IFC schema are not needed for particular use cases. For example, some use cases do not require geometry or particular domain data (MEP, Architectural, Infra, …). When leaving out geometry, which is seldom used efficiently using semantic web tools, the following ifcOWL data constructs can easily be left out.
Transforming ifcOWL graphs?
Diverse generic semantic web software libraries and tools are available that allow to restructure RDF graphs into alternative RDF graphs, making them simpler and easier to use. Depending on the use case, alternative RDF graphs can thus be generated, directly linked to the original.
One example converter was built in JAVA (not openly available, send requests to Pieter Pauwels). This converter takes an ifcOWL graph as input, strips it from a number of IFC entities and types (mostly geometric entities and types) and restructures key parts of the ifcOWL graph. This results in a simpler RDF graph, with information structured as displayed in the below screenshots. For example, properties are now directly available as datatype properties directly linked to entities; data attributes are now available as direct datatype properties; and ‘n-ary relationships’ are now resolved into direct object properties.
An example graph
Below is a sample IFC-SPF model, an ifcOWL RDF graph and a corresponding simplified version of the same graph. The above graph transformations have been applied in the simplified graph.
Note that a number of entities has been removed from the ifcOWL graph by the simplifier tool. In particular those parts that are seldom used in a linked data or semantic web context were removed (geometry and visual representation). This was based on the IFC2X3 TC1 architecture diagram that is supplied by BuildingSMART (see image below).
The entities and types for the following parts of the IFC standard were removed:
- presentation resource
- presentation appearance resource
- presentation definition resource
- profile resource
- representation resource
- topology resource
- geometry resource
- geometric model resource
- geometric constraint resource
Depending on the use case, it makes sense to keep out other parts of the ifcOWL graphs in order to make the graphs easier to use in industrial contexts.