IFC转换为OWL并在Protege中查看

时间：2024-02-16 15:08:40

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都能正确地显示了。

相关文章