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:
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.
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)
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):
