IFC and taxonomies

Developers
,
1

Hi all,

  1. Anyone knows IFC4 ADD2 TC1 is developed based on which taxonomy? At first glance, it looks like building components taxonomy but has extra classes and types.

  2. Also, how can IFC support granular assets? As I see IFC has IfcElementAssembly and IfcElementComponent and IfcBuildingElementPart, but how can I have Sets and Parts?

For example:

Building%20Classification%20-%20Ehsan%20Azari
Building%20Classification%20-%20Ehsan%20Azari2585×1881 733 KB

Hook Bolt Set has Hook Bolt Reciever and Hook Bolt Blocker as parts, which:
Hook Bolt Set has a relationship with Window
Hook Bolt Receiver has a relationship with Hook Bolt Set
Hook Bolt Blocker has a relationship with Hook Bolt Receiver and Hook Bolt Set

2

I think I found the first one:

IfcObjectDefinition

IfcObjectDefinition is split into object occurrences and object types. IfcObject captures object occurrences such as a product installation having serial number and physical placement. IfcTypeObject captures type definitions (or templates) such as a product type having a particular model number and common shape. Occurrences and types are further subdivided into six fundamental concepts: actors (“who”), controls (“why”), groups (“what”), products (“where”), processes (“when”), and resources (“how”).

  • IfcActor represents people or organizations.
  • IfcControl represents rules controlling time, cost, or scope such as work orders.
  • IfcGroup represents collections of objects for particular purpose such as electrical circuits.
  • IfcProduct represents occurrences in space such as physical building elements and spatial locations.
  • IfcProcess represents occurrences in time such as tasks, events, and procedures.
  • IfcResource represents usage of something with limited availability such as materials, labor, and equipment.

Reference: Industry Foundation Classes (IFC)

3

Personally, I think Product should be product, it’s odd to me: " IfcProduct represents occurrences in space such as physical building elements and spatial locations."

Products are processed, finished items that are offered for sale

So, what about subdivide IfcObjectDefinition into “seven” fundamental concepts:

  1. actors (“who”),
  2. context (“where”),
  3. controls (“why”),
  4. groups (“what”),
  5. products (“which”),
  6. processes (“when”),
  7. resources (“how”).

I mean IfcContext represents “where”: represents occurrences in space

Then I think we can move IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace, and even the whole IfcSpatialElement into IfcContext

Then IfcContext will contain:
IfcProject
IfcProjectLibrary
IfcSite
IfcBuilding
IfcBuildingStorey
IfcSpace

And IfcProduct will represent anything related to products

Alternative: Or have that six fundamental concepts, but change products (“where”) to products (“which”) and move IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace, and even the whole IfcSpatialElement into IfcContext

4

Dear ReD_CoDE. Personally, I agree with you that IFC, as a Building Data Model, should keep things simple for the building domain. But, at the origins IFC is a restrict specification of STEP, which is, in turn, a concret model built upon EXPRESS. This means a chain of concepts over concepts, thus the simplicity of knowledge representation was partially lost, I think. Anyway, that’s the World and it’s standards. I consider not to fight against the world.

5

Hi Marcelo, I’m happy see experts like you who know the current issues. And yes IFC is a standard, but I don’t think examining new ways and alternatives be a bad idea

What am I going to do is even more important than Building Description System - BDS project in 1975

And I explained it with some buildingSMART friends privately, and even maybe see it in IfcDoc in the near future

I need to re-build IFC to support my requirements