IFC as four main modules, each optional

Developers
1

IFC is about spatial, physical and process entities. These are the three modules which an application may or may not support.

At the bottom, there are plenty of questions about the multiple geometric representations that are available and how to manage the fact that some applications and use-cases need all or none or some or whatever.

Also at the bottom level is the Ifc Constraint schema. I am a fan, and I am pleased that little by little others are discovering it. In fact, I think its so good it should be promoted to be the fourth top module. Constraints such as objectives and metrics need to be derived from ifcRoot.

How does this work? An application can choose which and how many of the four to support.

(C) AEC3 (and Solibri) have been using Ifc Constraint model in a standalone manner for a decade. Many users, especially designers and specifiers would like to be able to specify requirements on other top level things too. Other control elements might be in here. The main external relationship is IfcRelConstrains(this, somethings in one of the other modules) . The main internal relationship is IfcRelDetermines(this, others)

(S) The spatial structure including Site and grids and alignments and spaces (but excluding IFC facility) should form the second top module to allow the “nominated framework” to be described. This module needs the simple geometry of grids and the advanced geometry of alignments. The main external relationship is IfcRelContains(this, something in one of the other modules) . The main internal relationships are IfcRelAdjoins(this, others) and
IfcRelComprises(this, others)

(P) The third module is all the physical elements, from all the so-called domains and including ifc facility. It would be great if we also rationalised them so that any application that can do one physical entity can do them all. Lots of geometry and symbology here. The main external relationship is IfcRelBounds(this, something in one of the other modules) . The main internal relationships are IfcRelTouches(this, others)
IfcRelAssembles(this, others) .

(W) The fourth module is the work (process) model (Ifcproject, tasks, work-plans, task-types, events, processes) such as would be produced from Microsoft project etc. This module will include cost (every process costs), and actors and consumable resources. The main external relationship is IfcRelModifies(this, something in one of the other modules) . The main internal relationships are IfcRelSequences(this, others) and IfcRelBreaksdown(this, others)

Thereby any app can be judged to support C/S/P/W so revit is -/S/P/-

2

This sounds like a fun way to talk about the scope of a BIM app :slight_smile:

“Judged to support” can be debatable. Does Revit support “S”, if it cannot actually support multiple sites, multiple buildings, or COMPLEX/ELEMENT/PARTIAL relationships, or the more obscure IfcSpatialElement subclasses?

3

@nn1 What about instead of spatial and leaving facility out, the module was “context”, including spatial, site, and new facility concepts. So, remodularization was a concept I was sketching/playing with in Vilnius. But I also think there are couple other key core moves and modules that might help, as well. Maybe I’m crazy, but consider this:

  • IfcRoot
    • IfcObjectDefinition
      • IfcProduct
      • IfcProductLibrary
    • IfcRelationshipDefiniton
    • IfcContextDefinition
      • IfcSite
      • IfcFacilty
      • IfcProject
      • IfcGroup
      • IfcZone
      • IfcSystem
      • IfcSpace
      • IfcPosition/Alignment
      • …
    • IfcPropertyDefintion
    • IfcProcessDefintion
      • IfcProcess
      • IfcActor
      • IfcResource
      • IfcControl
      • …
    • IfcGeometricDefintion

(It’s not complete, but hopefully you get the point)

That does add up to 6 core modules instead, but the subtleties of how the modules could be combined for various kinds of support are important. Many applications have geometry/object modeling as a core feature, but may not require process definitions. Or applications that specialize in processes and properties, but could care less about actual geometry.

Everything below the Ifc…Definition level would also have an Ifc…Type. You could also then simplify the deeply nested hierarchies currently existing, creating a broader, yet shallower structure, rather than a narrow and deep one.

4

I think that your ‘Context’ module mixes spatial, physical and process entities which might be unhelpful and inelegant.

I do see value in a generic IfcContext entity which remains mandatory, to identify the exchange or model and carry any unit definitions.

Geometry and location should not be mandatory on physical or spatial entities, nor should dates and durations be mandatory on process entities

However the strength of IFC is the specific objects like IfcWall, IfcDoor, IfcFixing, the weakness is that they have such unnecessarily varied implementation details. Rationalising the tree with property sets is far more useful and powerful compared with pruning the tree.

Regards,

Nick.

Nicholas Nisbet FRSA MA(Cantab) DipArch(UNL)

Director: AEC3 UK Ltd

Direct: +44 (0) 1494 714 933

Mobile: +44 (0) 781 616 8554

image001.jpg

Fellow Royal Society of Arts

Fellow buildingSMART International and buildingSMART UKI

Leader: buildingSMART International Regulatory Room

Vice-Chair: buildingSMART UKI Chapter

Member: UK BSI CB/5 Digitalization of the built environment and B555 Construction Information

Development of ISO 19650 part 4

Revision of BS 5606 Guide to accuracy in building and its representation in BIM.

Revision of ISO 12911 BIM Guidance Framework

Development of ISO 22014 on BIM library objects

Revision of ISO 15686-4 Buildings and constructed assets - Service life planning: Part 4, using IFC

********** Confidentiality Notice **********.

This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.

5

I’ve started to think about the IFC structure based on “Occurrences” and I think it causes better results that is so close to Project Management - PM and Facility Management - FM frameworks in the industry

Who = People (Actor)
Why = Controls
What = Systems (System, Element (Product is part of Element), Part)
Where = Environment (Project, Site, Facility, FacilityPart, …, Building, BuildingPart, BuildingStory, Zone, Space)
When = Processes
How = Resources

However, this is just preliminary thoughts (I’m thinking about Why, When and How in another way too) and for sure it will change during the time, but I think it would be worthy we all share different ideas and find the best ones

I like Spatial, Physical and Process, (and maybe some extra modules too) idea

6

Personally I like the way you @jwouellette more than the way @nn1 porpuses
Why?
If we divide IFC to Spatial, Physical, Process, …, as modules, we have to have two-three different parts that are repeating, especially in Spatial and Physical modules, like Object and Location

7

IFC4.2 schema entities:

  • Over 45% of IFC schema is related to “Presentation and Representation” like Geometry/Topology, etc (326 entities)
  • Over 40% is related to Product mainly Element (268 entities)
  • There’re other small but effective parts like:
    • Relationship (60 entities)
    • Property (30 entities)
    • Quantity (11 entities)
    • Environment [anything related to location] (27 entities)
    • Resource (16 entities)
    • Process (8 entities plus 7 entities (IfcSchedulingTime))
    • Control (11 entities)
    • People [Actor] (5 entities)
    • etc

So, big parts are Product/Element and what I call Model which can be divided into “Presentation & Representation” which I’ve started to borrow it from Product Manufacturing Information (PMI)