BIMServer and the majority of solutions in the industry work for/with IFC output as .ifc (STEP) or .ifcXML (XML) files
#1=IFCPERSON($,$,$,$,$,$,$,$);
.ifc (as output) is so close to SQL structure and can be converted to SQL database as aforementioned
Converting .ifc file to SQL is an obvious method today in the industry, this is not issue
But IFC Schema is different
I think EXPRESS or UML are just toolsets to develop schemas and databases and for sure UML, especially UML2 will help (And also people who know ArchiMate)
The main point is that IFC will develop based on Object-Oriented approach or Relational or Object-Relational approach?
The idea of developing schemas based on Object-Oriented comes from those old-days when just some few companies like Microsoft were in the industry, I accept that today the majority of languages are Object-Oriented but are not good for schema and database development
To UML: As far as I know, UML is just a graphical schema visualization like EXPRESS-G. ifcDoc therefore also has an output option in UML instead of EXPRESS-G.
In any case, UML is a better representation than EXPRESS-G, since in EXPRESS-G inheritance and relationships can hardly be distinguished from each other.
XSD is derivied from EXPRESS. EXPRESS have more informations/rules than XSD.
OWL is also derived from EXPRESS and I think the idea behind is better understanding like UML.
For me the best common root of all is a self designed relational database to put all aspects together including bSDD.
The (not only) UML-design-tool Enterprise Architect for example use also a relational database as its underlaying system. But to switch to a modelling tool makes you dependent on the data model of the modelling-tool.
But to switch to a modelling tool makes you dependent on the data model of the modelling-tool.
This is why I introduced IfcXtreme project, in practice, it would be a custom-made schema modeling and editor which end users can put entities on canvas and set and control relationships, add templates and Psets, add rules, set processes, so on
In 2017, i used to work alone around transposing IFC data into SQL format.
I came to the conclusion that it was not viable to reproduce every IFC concept in SQL format. Because we must not lose sight of the fact that each syntactic modification of the IFC would then have structural repercussions.
Also, I decided to create a meta-model type approach (the strategy number 5)
A first database serves as syntactic repositories; any IFC syntax element is placed on the same level to be referenced by a unique ID : objects, numerators, enumerator values, data types, PSET, Syntax version, … ; This is very advantageous, because it allows you to create dynamic and multicultural objects. If something change in IFC, you just add it in data.
Then there is the second SQL storage format dedicated to project data: An IFC_ENTITY table for the inventory of IFC entities, and a table for properties and property values. A DLL is responsible for reading/writing what we want and hides the SQL operations. The objects are reworked to generate an overloaded flow that casts the values and renames the properties with the translations in effect for the language used in the presentation layer.
May someone else already did this before me… i wasn’t smart enough to check it. Anyway, whatever: I was very alone in doing all this and i choose to call it IFCX.
You are right. But, the fact is SQL format is missing. So, it means we need something like a wrapper to let server work with ifc data any stored support.
Software vendors are indeed developing their own databases for buildings and infrastructure through Common Data Environments (CDEs). Perhaps their absence here is due to a reluctance to disclose their proprietary methods. However, I’m curious about how a relational database addresses data exchange issues. Are you suggesting that buildingSMART International (bSI) should tackle this?
IFC data is object oriented data supposed to be used in OOPL. Object oriented data is not easy to store in relational database at all.
Please read about the “Object-relational impedance mismatch” on English Wikipedia. This article will explain why it is difficult to store object oriented data in tables in relational databases.
Storage is also only one aspect of the whole problem that has to be considered. When you take a decision on a database paradigm or database design for IFC data.
You also have to consider the possibilities to analyze and query the data in the database (once it has been stored in the database already).
IFC contains too many relationships to be efficiently queried in a relational database. There will be too many JOIN:s. And SQL queries will be too complicated too soon.
Instead it is necessary to look for other types of databases to store object oriented data.
The object database never was a hit. Nobody ever suceeded to implement the object query language (OQL).
Graph databases can handle lots of relationships. I think that storing IFC data in graph databases is the best option at the current state of technology.
There are many graph databases to choose from and Graph Query Language (GQL) is also a new ISO standard. The only ISO database query language besides SQL.
You might be able to store the data in a relational database, but it will be a lot of problems to analyze this data efficiently using SQL.
I recommend to look for and read the article:
“IFC-graph for facilitating building information access and query”
It explains how to store and query IFC data in a graph database.
IFCWebServer.org supports since 2017 converting IFC models to Neo4J Graph Database and running interactive queries to extract information or show filtering results on the fly in the online viewer.
From my long experience in this domain I should say that converting the IFC model using “one-to-one” mapping approach has a lot of limitations and additional work should be done to improve the database by removing redundant nodes and relationships, this can be done based on each application case.
:
However, I’m curious about how a relational database addresses data exchange issues. Are you suggesting that buildingSMART International (bSI) should tackle this?