buildingSMART Forums

How to map between IFC and Product Data Templates in buildingSMART Data Dictionary (bSDD)?

In Product Room, in the working group “Product Data Templates (PDT)”, we want to define a consistent way of making relations between IFC concepts and Product Data Templates in buildingSMART Data Dictionary (bSDD). Through a buildingSMART project called “Integration of bSDD into the IfcDoc tool” there is already established some rules how to do this. However, the PDT working group believes the relations should be made following the document that is attached to this topic. The principle is basically the same, the main thing that is proposed to be done differently is to always use different concepts in BSDD for IFC representations (entities and properties) and concepts that come from other sources (like product standards etc.) opposed to merge concepts by using IFC as language on the concept. I believe this topic is not familiar with too many of you, but we decided to try reach out to a bigger audience in buildingSMART to see if we could generate some valuable inputs to our efforts.

Here is a link to a document that the group has produced:

IFC mapping to data templates

Thanks in advance for any inputs to this matter.

2 Likes

I believe that buildingSMART not only in bSDD (IFD), also in IFC should “learn” a lot from GS1

Personally believe IFC, especially IfcDoc project is not a successful project, so you in Product Room decided to follow an unsuccessful project?

Hope bSI cooperate more with GS1 to learn and to develop a well-structured project

I’m not sure if this helps: I have ported the EXPRESS-Schema of IFC4 to a SQL-Database with an ifcSchema-namespace and an ifcInstance-namespace with just a couple of tables (not the 782 Entity-classes). It is possible and it works. I just test including the psd-xml-files and qto-xml-files with referencial integrity to the Entitiy-Types. The main point is, if everything (all schema-information and all instances for many projects) is stored in a single database, everything would be easier to handle instead of using files for schemata and files for IFC-Models. This is not the direct solution for your open points, but maybe a way. As I know, this is also the starting-point of bSDD. If you want to know more about it, let me know.

We have the same approach and has started to focus on SQLite schema development

SQL schema will reduce entities and other classes which will bring a better performance

I think SQLite is great to develop schemas and databases based on
And JSON is good for real-time usages like IoT usages

From 2013 they are developing PDT and PDS and still are in the beginning :face_with_hand_over_mouth:

The linked document “Mapping product data templates to IFC through bSDD” [1] refers to a document “Mapping IFC to bSDD” [2].
[2] refers to a database (IFC4.SQL) with over 150 tables (much of them have layout-informations) .
This database (as I understood) is now included into the bSDD-database.
The bSDD-database will have now much more than 150 tables.
Who will understand a database with so much tables?

I think, documentation and schema-description are different things.
Shure, the documentation must match to the schema, but this you can do by a checking-procedure.
The reason to divide this is, that you will reduce the problem to combine only
(1) bSDD
(2) ifcSchema (without documentation)

To (1): The repesentation of the bSDD-schema PSD_IFC4.xsd is described at section (D) in Store, modify and retrieve ifc-data with ifcSQL .

To (2):
The repesentation of the EXPRESS-schema is described at section (F) in Store, modify and retrieve ifc-data with ifcSQL .
IFC-data-model from a bird’s-eye view described with UML (extract from picture 2 in IFC for relational databases - ifcSQL:
UML_ifc_entity_attributes_Bock

The next picture show, how to connect bSDD and IFC-types (ER-diagramm from XSD-schema/XML-PSET-files) referring the type-table of [ifcSchema].[Type] in Section (F):


I think, this also could be more simplified: