IFC为建筑信息模型的存储提供了一个准则。IFC文件有许多表述模式，例如STEP、RDF、OWL。理论上来说，这些格式都是可以互相转化的。STEP的可读性不佳，但是转化成RDF/OWL后，就可以在Protege中进行查看，从而进一步了解IFC文件的组织格式。
最快捷的方式：在Revit中创建一个项目并导出为IFC，这个模型包括四面墙，两个自定义族，导出格式为IFC2X3。
https://github.com/pipauwel/IFCtoRDF提供了一个将IFC转化为RDF的工具。这个工具可以将.IFC后缀的文件转化为.TTL，支持以下IFC格式：
java -jar .\IFCtoRDF-0.4-shaded.jar .\test.ifc .\testrdf.ttl用Protege打开RDF文件后，可以看到此文件包含的类与属性。
在类下可以看到该文件包括的所有ifc类，以及它们的实例。如IfcWallStandardCase就有四个实例，对应四堵墙：
然而看不到任何的Object properties和Data properties。这是因为RDF不区分什么object和data properties，这点和STEP类似。所以所有的properties都以Annotation properties的方式呈现，如图：
答案是肯定的。从buildingSMART中下载ISO标准版本、TTL格式的IFC文档并用Protege打开，可以看到各类属性。首先是Data Property：
以及Object Properties：
那么就有一个问题：IFC2RDF得到的RDF文件，annotation properties和标准版本的IFC中是否是一一对应的呢？
首先是hasInteger一类的Data properties，答案是：yes。
Object properties的对应稍微复杂一点。以ifwallstandardcase中一堵墙的objectPlacement_IfcProduct作为例子，返回在IFC标准文件的Object properties搜索对应项。
我们发现，确实有一项称为ObjectPlacement的object properties，其domain为IfcProduct，Ranges为IfcObjectPlacement。
其他的properites大抵相同，也就是说_之前的是该object properties的URI，_之后的是该properties的domain。了解了这一点之后，我们就可以知道如何将IFC2RDF产生的文件进一步转化为OWL了。
原文：https://www.cnblogs.com/OverloadBachPunk/p/14389202.html