IFC转换为RDF并在Protege中查看
IFC为建筑信息模型的存储提供了一个准则。IFC文件有许多表述模式，例如STEP、RDF、OWL。理论上来说，这些格式都是可以互相转化的。STEP的可读性不佳，但是转化成RDF/OWL后，就可以在Protege中进行查看，从而进一步了解IFC文件的组织格式。
创建一个IFC文件并导出
最快捷的方式：在Revit中创建一个项目并导出为IFC，这个模型包括四面墙，两个自定义族，导出格式为IFC2X3。
IFC2RDF
https://github.com/pipauwel/IFCtoRDF 提供了一个将IFC转化为RDF的工具。这个工具可以将.IFC后缀的文件转化为.TTL，支持以下IFC格式：
- IFC2X3_TC1
- IFC4_ADD1
- IFC4_ADD2
- IFC4_ADD2_TC1
- IFC4x1
- IFC4
- IFC4x3_RC1
下载其jar包后，与ifc文件放在同一目录下，打开当前目录的cmd输入：java -jar .\IFCtoRDF-0.4-shaded.jar .\test.ifc .\testrdf.ttl即在目录下生成了RDF文件。
在Protege下查看RDF文件
用Protege打开RDF文件后，可以看到此文件包含的类与属性。
IFC2RDF：消失的属性
在类下可以看到该文件包括的所有ifc类，以及它们的实例。如IfcWallStandardCase就有四个实例，对应四堵墙：
然而看不到任何的Object properties和Data properties。所以所有的properties都以Annotation properties的方式呈现，如图：
IFC中原先定义了Object和data properties吗？
答案是肯定的。从buildingSMART中下载ISO标准版本、TTL格式的IFC文档并用Protege打开，可以看到各类属性。首先是Data Property：
以及Object Properties：
那么就有一个问题：IFC2RDF得到的RDF文件，annotation properties和标准版本的IFC中是否是一一对应的呢？
IFC2RDF的缺陷，是否能够改正？
Data properties的对应
首先是hasInteger一类的Data properties，答案是：yes。
Object properties的对应
Object properties的对应稍微复杂一点。以ifwallstandardcase中一堵墙的objectPlacement_IfcProduct作为例子，返回在IFC标准文件的Object properties搜索对应项。
我们发现，确实有一项称为ObjectPlacement的object properties，其domain为IfcProduct，Ranges为IfcObjectPlacement。
其他的properites大抵相同，也就是说_之前的是该object properties的URI，_之后的是该properties的domain。了解了这一点之后，我们就可以知道如何将IFC2RDF产生的文件进一步转化为OWL了。
问题排查
问题之一：错误的前缀
IFC2RDF错误地使用了前缀，经过转换后，ttl文件中会有这样的前缀声明：
# baseURI: http://linkedbuildingdata.net/ifc/resources20210221_142133/
# imports: http://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL
@prefix ifc: <http://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL#> .
@prefix inst: <http://linkedbuildingdata.net/ifc/resources20210221_142133/> .
@prefix list: <https://w3id.org/list#> .
@prefix express: <https://w3id.org/express#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .需要注意的是@prefix ifc: <http://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL#> .在官方的IFCOWL定义中，其URI为https://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL#。http和https的差别会使得预先定义好的OWL无法被导入。结局方法是把遗漏的“s”加上。
问题之二：遗漏的导入
IFC2RDF使用了@prefix expr: <https://w3id.org/express#> .这个模块，但是没有进行导入。这个问题可以通过手动添加导入解决，如果能够成功导入https://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL#的话，由于后者对前者存在依赖，也会间接导入。
问题之三：无法从网络资源导入
在导入https://standards.buildingsmart.org/IFC/DEV/IFC2x3/TC1/OWL#时报错。这可能是对方服务器导致的，结局方法是从SMARTbuiding上保存TTL格式的IFC文件到本地，然后在Protege中进行手动导入。
以上步骤完成后，可以看到Object Properties和Data Properties都能正确地显示了。
