IFC for relational databases - ifcSQL

[ReD_CoDE]

ExtrudedAreaSolid

This is why I believe that a hybrid methodology can help with
Combination of SQLite and XML or JSON or JavaScript or any other modern technology

SQLite can refer to all of them? a PK can has many 1:1, 1:M, M:M relationships?
Several number of refers is not issue, because at the moment other methods like EXPRESS-SPF, XML, OWL, JSON, all “have to” handle this huge data, datatypes and relationships

I’m not programmer and mainly these days have focused on our startup
But I believe that “if” buildingSMART and some corporations and organizations that control buildingSMART want they can improve IFC or develop a modern one

I think this can help us find our way (a hybrid approach is needed):
https://www.quora.com/What-is-the-difference-between-a-knowledge-graph-and-a-graph-database/answer/Kingsley-Uyi-Idehen

[sergej]

FYI relational database != graph database.

[ReD_CoDE]

FYI I said a mixed usage --> Relational + Graph

I believe that a mixed approach is good (SQL and No-SQL),
A combination of SQLite, XML and JSON and RDF-OWL
Mainly JSON for real-time usages like IoT

SQLite can’t solve the whole issues alone, but will solve part of and other technologies and methodologies will solve another parts

So for relational side let’s choose SQLite and for other part use Object-Oriented or Graph (Or even both) to build a schema which is more modern and also more flexible

[ylcnky]

While Relational + Graph database combination is technically possible, feasibility and practicality of handling two databases at the same time can be a critical issue.
@bsbock #6 looks like a better approach unless rule checking is a critical requirement. Is there a particular reason for why you want to store in a relational database? Have you reviewed NoSQL alternatives?
Meanwhile, I came up with this paper.

isprs-archives-XLI-B2-625-2016.pdf

[ReD_CoDE]

Maybe I’m wrong, but as I know No-SQL doesn’t have a good performance like SQL (but for sure maybe a mixed approach SQL + No-SQL be good, maybe)

It seems that Esri uses a relational approach and this document explains relationships, especially “Relationship Class - Navigation Property” which I think would be useful

http://resources.esri.com/help/9.3/arcgisengine/dotnet/2e097482-4f99-4224-896e-8027e6ab883e.htm

[bsbock]

Meanwhile, I came up with this paper.

What the (very interesting) paper speak about is Strategy no. 4:
(+) recognition value
(+) rule checking on base-classes possible
(-) don’t work with SELECT-Types (by use of FOREIGN KEY(…) REFERENCES(…) )
(-) too much tables (more confusing than strategy no. 3)

[bsbock]

@bsbock #6 looks like a better approach unless rule checking is a critical requirement.

With Strategy no. 6 rule checking workes fine with triggers. Give me some days for posting an example.

[bsbock]

Is there a particular reason for why you want to store in a relational database? Have you reviewed NoSQL alternatives?

My reasons are described here:

IFC SQLite Project

ok, let’s start with IFC for relational databases. First of all: why to do this? For me the benefits of sql based working are well known data-access (like XML too), no parser required integrated referencial integrity (not by a seperate test) typesave in base-types multiuser functionality (many users can work on the same datapool at the same time) The points 3) and 4) are - as far as I know - not capabilities of SQLite. But SQLite could be a possible target for IFC-Data. It is not only a S…

But most of all: Leaving the world of a thousand files. Growing up from Luggage to Wardrobe
as shown in the picture in IFC for relational databases - ifcSQL

[sergej]

I was going from “SQLite and XML or JSON or JavaScript or any other modern technology” which would essentially mean a hybrid of a database, some sort of encoding format and a programming language. Somewhat mixing pears and apples which is happening here also:

“So for relational side let’s choose SQLite and for other part use Object-Oriented or Graph (Or even both) to build a schema which is more modern and also more flexible”

The IFC schema does not forbid encoding in a database format, in fact SQLite is mentioned as a possible format here. The scheme would not be more modern by being “encoded” into a database. The schema is the schema and encoding of the schema is a format of some kind.

It is not as though software vendors do not have and are working on their own versions of databases for buildings and infrastructure in the form of CDEs. Maybe they are not participating here because they do not want to share their secrets. But how does a relational database solve the data exchange aspect? Are you proposing that bSI does this?

[ReD_CoDE]

Thanks Sergej, I know the schema is schema and database is a database

I’m just practicing to find a way to build the schema based on “reducing schema tree layers from 4-11 to 1-4”

“After ISO 19650, IFC, especially IDM needs some improvements, so “WHAT IF ISO BIM, CLASSIFICATION AND IFC BE MORE CLOSE TO EACH OTHER AND BUILD A BETTER SOLUTION FOR THE INDUSTRY””

As said before we can reduce IFC schema layers and instead use classifications to say a window is an object, a product, an element, a building element

Also, ISO 19650 naming approach can help us develop a better way than just GUID/UUID (in 128-bit approach) for identification

And mainly I’ve focused on developing a “middleware”

Yes, IFC SQLite mentioned there, but it seems that after Tim Chipman from Arup left, nobody has worked on IfcDoc and IFC related projects, it seems that he was playing a key role inside the bSI

IfcDoc exports schema to SQL but have you checked it?

Converting .ifc file to SQL is an obvious method today in the industry, this is not issue
But developing IFC and also IFD, and schema based on relational approach like SQLite (as a file) or SQL (as server solution) is important

And yes, maybe some say it’s CDE, but it’s more than, it’s adding automation, control, in general logic to the schema and to its databases/solutions

So, maybe today some have this as secrets, but I want to give it as a gift to all (specially to a country that has started a national degital platform and soon I will be part of them and their movement). It’s better others find another secrets if this is their secret

[bsbock]

IfcDoc exports schema to SQL but have you checked it?

Where can I find the ifcDoc-Schema-Export to SQL? Save as MDB produces no file for me.

[bsbock]

The scheme would not be more modern by being “encoded” into a database. The schema is the schema and encoding of the schema is a format of some kind.

• IFC-STEP is a textfile for one project with a hint to the express-schema which you can test separately
• ifcXML is a wellknown textfile for one project with an explicit link to the XSD-schema which you can test separately
• ifcSQL could be a database, which include data of many projects including the schema and allows only inserts and updates which match to the schema

[ReD_CoDE]

In IfcDoc you can export publications to any output you want
If need help let me know to explain the process

So the output would be HTML documentation plus formats you have chosen

Forum doesn’t let upload SQL file, so uploaded it here: https://gofile.io/?c=6DXMTU

It seems that bSI has started to focus on UML, I hope UML 2, but again with Object-Oriented approach, so I think O-O is good, but relational approach or Object-Relational approach is better

[bsbock]

Thank you for upload, @ReD_CoDE!

The result looks like this:

CREATE TABLE IfcObject (oid INTEGER,
GlobalId TEXT,
OwnerHistory INTEGER,
Name TEXT,
Description TEXT,
ObjectType TEXT);
…
CREATE TABLE IfcActorRole (oid INTEGER,
Role VARCHAR,
UserDefinedRole TEXT,
Description TEXT);
…
IfcObject is abstract and IfcActorRole is derived from IfcObject, which contains only the attributes, that are not contained in IfcObject.
This is Strategy no. 4:
Store every inheritance-step in its own table(782).
(+) recognition value
(+) rule checking on base-classes possible
(-) don’t work with (every) SELECT-Types
(-) too much tables (more confusing than strategy no. 3)

[jwouellette]

1. Has anyone looked at bimserver.org and discussed/analyzed how they’ve executed their IFC database & server? Is it effective? At least a beginning? It is one way that IS working currently and meeting the needs of many…

2. What if the IFC schema had its root definition/description in UML and then expressed more specifically as EXPRESS, XSD, OWL, etc… Would this help in establishing flexibility between different implementations, but maintain a central, overall context and semantic cohesiveness? Would it help in then defining different database implementations from a common root?

Please also refer to my reply in another topic:

What would you like to see most in the "modernization" of IFC?

For the past few months, there has been discussion within the bSI technical community to look forward at the architecture of IFC. As part of this discussion, it is important to understand that there are different components, such as: Description Method - including the Definition Language (UML vs. EXPRESS, etc.) and Data Formats (STEP, XML, JSON, etc.) Specification - including the structure and content of the schema and possible extensions like Taxonomy and Data Dictionary Implementation M…

[ReD_CoDE]

1. 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

2. 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

[bsbock]

Has anyone looked at bimserver.org and discussed/analyzed how they’ve executed their IFC database & server? Is it effective? At least a beginning? It is one way that IS working currently and meeting the needs of many…

yes, I looked at bimserver.org, but found no introductory application example.

[bsbock]

What if the IFC schema had its root definition/description in UML and then expressed more specifically as EXPRESS, XSD, OWL, etc… Would this help in establishing flexibility between different implementations, but maintain a central, overall context and semantic cohesiveness? Would it help in then defining different database implementations from a common root?

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.

[ReD_CoDE]

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

It will open a door to a modern IfcDoc

[ReD_CoDE]

@sergej I found the secret [2012-2017, 2017-2022 project] :