Several of us have been involved in conversations over the last couple of years about the “modernization” of IFC. I looked carefully to see if there was already a thread here addressing this issue specifically, and couldn’t find one, so early apologies if this is already addressed elsewhere.
First, I’ll start with a couple of existing discussions in the public realm on this topic. I wrote a Github issue for IFC-gen a little while back which, while not tackling IFC modernization directly, focuses on one aspect of that modernization which is a singular representation of the schema and its storage in Github. @jonm has already noted that a move to Github is under way.
@yorik mentioned in a FreeCAD BIM development news post that he’s working to “decouple” geometry creation and BIM semantics. His commentary there aligns with some things in the post by Tim that I earlier referenced around the size of IFC. Why do we have hundreds of entity types in the IFC spec when entities are just a representation, some properties, and some relationships?
And finally, I’ll provide the issues that I’ve talked about with members of this group before, but have not recorded in the open. These issues come from working very closely writing IFC parsing and code generation infrastructure over the last two years and starting to build a cloud-services business where we’re generating IFC data. Please keep in mind that these are not criticisms, just observations. I know that there were, at the time that many of these things were decided, good reasons for doing them.
IFC is designed to store stuff in files. I’ve actually had someone who was been involved in the IFC conversation for some time tell me that this is for archival purposes. Anyone who has IFC workflows for real projects currently will tell you that this is a bad setup. BIM data has outgrown file-based workflows. I also don’t buy the idea that we’ll be able to open a 2gb IFC file that we “archived” at any point in the future.
IFC is designed so that you have to have a “project” with at least one “building”. I’ve worked on lots of projects for which artificially injecting a “building” is just weird. During my time at Buro Happold, we worked on lots of canopies covering existing spaces for example.
IFC relationships are built for querying in relational databases. For many workflows, especially those in the cloud using nosql dbs, this is just bloat. Most developers, myself included, make the initial mistake of mapping IFC relationships to types in their class hierarchies when they can be better expressed as interfaces.
EXPRESS or XSD. Choose one. For things like functions and rules that are currently encoded in the EXPRESS schema but almost universally not implemented in software libraries derived therefrom, just author a nice specification document. Specs are written like this all the time. Better to have something that we all can read, then to have something that we all ignore.
To echo @TimDavies comment about naming: get rid of the “Ifc” prefix. This seems like a vestige of a time when programming languages didn’t have namespaces so you had to prefix everything. I’m reminded of my days as an iOS developer where all the APIs were called stuff like “NSObject”, which stood for NeXTSTEP.
Break up the specification into modules corresponding to the “domains”. It’s currently impossible using automated code generation from the spec to put stuff into modules, namespaces, etc. based on the domain because you just have one enormous spec.
The IfcDoc tool hampers adoption. This is probably the most controversial thing I’ll say in this entire conversation. If our first response to someone who wants to get started using the specification of IFC to build software libraries or other tooling for IFC is to download a windows-only application that contains the ability to generate documentation, mvds, etc. it’s too much.
Automate IFC validation. We should seriously consider adopting serialization formats for which there is abundant validation tooling available today, for free. As an example I can go to this JSON schema validator, enter my schema and my JSON and immediately be told what’s broken. JSON schema validation is built into development environments like Visual Studio Code and Visual Studio as well. If you don’t think this is important, I invite you to try and write a valid IFC file by hand. I know there is tooling for XSD validation as well, but I have yet to see a workflow where someone is using this in an automated way with IFC xmls or mvdxmls. Could be that I’m not looking hard enough. ADDED 6/20/19:
Find a better solution for SELECT types in EXPRESS. SELECTs are very powerful, but don’t have a good representation in many C-like programming languages. Language like Typescript with support for discriminated unions handle SELECTs better. This makes support for SELECTs across languages problematic. Also, many SELECT types are SELECT of SELECT which is mind-boggling. I’d be interested to see how these are handled in XML.
Consider publishing and supporting a set of schemas for web-based workflows. I realize that IFC is often serialized to XML. But is this representation the most compact representation that can be made? As workflows move to the cloud, LOTS of data is going to be passed around. Someone is going to pay for all of that and the difference between storing points as x: 5, y:5, z:5 and [5,5,5] is going to add up.
This is my short list of issues that I’ve had discussion around over the past months. I invite you all to comment on these or add the issues that you would like to see as part of the modernization discussion as well.
Thanks for posting Ian. I’d personally like to see many of these points be specifically discussed in their own threads (and I’ve referred or started some to the points I refer to below).
I think it’s fair that serialization has had a huge influence on the design (given it originated over 20 years ago) and that modernizing IFC will cause change. You can find some of my thoughts here: Industry Foundation Classes are a Data Schema, not a file format
I recall that I raised the model archive point in the technical room discussion in New York. 2GB ifc files should be scrutinized and implementations or models generating them should be altered.
This thread touches on the topic, IFC Backwards compatibility
There are constraints within the schema and “Implementer Agreements” that direct this scenario for IFC2x3 (and earlier I presume). These are better handled be specifc MVDs (that might be extensions of the official ones) for IFC4 and beyond . Certainly a lot of infrastructure projects won’t have a building.
This should also be discussed in a specific thread. As previously discussed, maybe there is an alternative superior choice although I don’t see it being json (as it doesn’t have official provision for common references, so this needs to be thought through).
This isn’t one I feel so strongly about, with the Ifc prefix you don’t get class name clashes when developing with an API (such as Revit or Tekla). If there is consensus on this certainly the schema to toolkit approach can be configured even if the serialization doesn’t change.
This actually already exists even if it’s not readily apparent. It’s certainly not evident in the long form version of the express schema and not in the xml. You can see it in the short form schemas.
I’d like to see serious improvements in this. To my mind the XSD schema needs to be improved but already I do use XML for schema validation without IFC specific tools. MVD can nominate requirements/constraints above and beyond schema and I’m not sure these can be captured in XSD. I’d also refer to this discussion. How to validate an IFC4 against an mvdxml
To reply the “What would you like to see most in the “modernization” of IFC?” question, I guess one favorite of mines would be to remove these rigid, mandatory rules like “All IFC files need to have exactly one IfcProject” (most projects are made of more than one IFC file these days anyway, and the IfcProject entity holds next to nothing) or “there must be at least one site and one building”. I’d love to be able to have IFC files that contain just a bunch of objects, no relationship or anything, specially not a fake one…
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
IFC right now tries to “do it all”, and more than that, it encourages to do it all in one file. (I’ve recently heard that you can inherit IFC properties from other files by sharing GUIDs, but it’s not exactly the same as referencing other files).
IFC needs to ensure that readability and authoring of plain text is maintained. Don’t lose the text streams. If BIM data ends up being a binary database blob …
I don’t think STEP (SPF) is a good choice and unlike @jonm don’t think XML and even Turtle are right choices (both have some issues), and JSON is not bad but maybe you all know a better as well as modern technology to implement IFC schema and .ifc files based on.
As I know SQLite has a better performance than R these days, so this is why I suggested starting “unfinished” IFC SQLite project
But I believe that a modern text-based solution or a hybrid one can solve the issues
Also, there’s a need to simplify IFC schema and have a well-structured architecture, and GUID is just one of the issues
In the next phase, we can think about binary approaches too that I have some ideas here too
Why after years even software vendors can’t develop a right IFC importer/exporter?
Why some software companies like Autodesk has built their own SDKs?
Why after years even those who know IFC well ask about IfcRel this or that?
Why IfcDoc has problems?
Why the majority of classifications don’t support IFC2X3 and IFC4 and others from Northern Europe countries have developed some hilarious classifications that still are in early stage?
And lot of other whys that I can add
Some countries have started their own national digital projects/platforms, and they are going to build a beautiful building based on “unsafe” foundation, IFC
Do you think IFC is good for automation? IoT? BIG Data? ML? DL? AI? or even for could platforms?
These days some talk about Industry 4.0 and Digital Twin(s) and I just give them a smile
I personally struggled a lot with the upper level elements like IfcProject, IfcSite which bind a single IfcBuilding per file. We should contain multiple buildings in a file while this also raises the file size depends on the size and details. I agree with @yorik to have more objects, but I believe relationships might be valuable also for other purposes. I worked on some graph analytics on a >2GB ifc file just to see what kind of results would appear. Although I don’t have clear suggestions regarding what kind of relationships would be defined extra (may be a separate thread), I found existing relationships in ifc standard does not bring sth new with one building, since you can reach similar results with DB queries.
I fully agree with the argument that ifc describing (one) site, building or project is not working. I think most of the civil works is done using ifc parts per assembly per phase per disciplibe etc. Merging ifc should be made more simple.
Besides that i would like to see a improvements and efforts taken to bridge the gap with what is called ‘level 1 bim’ (i personally hate that typology). In other words, make it in ifc more easy to incorporate linework and ‘stupid’ cad design. Either 2d first and 3d, or vice versa.
Point is ifc should be more capable of simple mixing and fushion of data. For those who see it as just a an other fileformat.
As of this commit, FreeCAD is now able to export an IFC file without any site, building or storey. Example file: without-building-structure.ifc (11.6 KB) (please don’t mind the geometry defect in the column). The objects are simply aggregated directly under the IfcProject. Actually, I haven’t found in the IFC docs anything that says this is forbidden. The IfcRelAggregates apparently allows to aggregate any object type. Anyone knows where the mandatory building story comes from? I don’t remember…
This file opens OK in FreeCAD, IfcPlusPlus and ArchiCAD so far. Revit opens it, but merges all objects under a single one…
The IfcProject, however, I couldn’t do without, because that’s where all the units are defined. I suppose you could actually have several projects with different units in a same file, that could make sense some day… So probably that one has to stay.
I think that replies your question too @ReD_CoDE ?
I see the final output which is STEP files, and say: OK! Let’s accept that all are happy with STEP at the output
How can we have “shallower tree” and “single entities” and “simplified relationships” inside the schema.
The output can be this:
#1=IFCPERSON($,$,'Yorik van Havre',$,$,$,$,$);
#2=IFCORGANIZATION($,'uncreated.net',$,$,$);
#3=IFCPERSONANDORGANIZATION(#1,#2,$);
#4=IFCAPPLICATION(#2,'0.19 build 16944 (Git)','FreeCAD','118df2cf_ed21_438e_a41');
#5=IFCOWNERHISTORY(#3,#4,$,.ADDED.,$,#3,#4,1560119567);
But what if we be able to “move all types, rules, functions, … needed into a single entity” and “have simplified relationships” not messy ones that cause a lot of misunderstandings even between people who know IFC well
I don’t know is it possible or not, but it seems that possible. I should ask from people who know UML and software architecture development I think
It is true that you need 5 lines for something that could be said in one (Yorik, FreeCAD, date), but that’s how IFC works… Any 2D profile is also made of 10, 15 lines when it could in theory be only one (a list of points, basically), it’s hard to imagine that could be changed easily. The format is made for modularity (you can easily reuse any of the “pieces” anywhere else) rather than compactness
The idea of being able to synthesize is attractive, though… (something like: IFCOWNERHISTORYCOMPACT('Yorik','FreeCAD',1560119567) maybe?
What about IFCCLOSED2DPROFILECOMPACT((0,0),(100,0),(100,100),(0,100))
@ReD_CoDE, @yorik - are you guys serious? Exactly because of complex concepts and relationships (with inheritance so that attributes are not redundant) that everyone can agree on (ISG and certification) we can even come close to start exchanging data. A 200MB model can have all kinds of different geometry representations for various objects. Your " IFCCLOSED2DPROFILECOMPACT" is broken with an arc already, let alone something “fancy”. Have you taken a look at IfcIndexedPolyCurve?
Your owner history example goes away from the concept of object oriented models. You want to parse strings where you should have structures and types that allow you to get away from compliance errors. You could go all the way with simplification -> go back to PDFs. In the end, an IFC SPF does not need to be human readable. Isn¨t that the whole point? Digitization and automation.
Relax, not trying to push a standard change here, just playing with the idea, which is what this topic proposes… In any case, providing alternative, compact ways to “reduce” (maybe REDUX is cooler than COMPACT ) some “bunches” of data does not mean everybody would be forced to use it…
I was referring you to existing possibilities. I think IfcIndexedPolyCurve does what you ask and more. Why would you need another redundant definition in a schema that is already quite substantial. Just means less implementers will support it.
yes, the IfcIndexedPolyCurve provides you with this capability. See attached a document that was created to justify the addition of a new class. And please have in mind, that IFC is currently used by >250 software applications worldwide, with millions of IFC files around - so one can’t just “do and change”.
Nevertheless - thinking about a new generation of IFC using modern, web-based technology is needed, while maintaining the existing technology stack to guarantee compatibility.
) some “bunches” of data does not mean everybody would be forced to use it…