# IFC and taxonomies **URL:** \ **Category:** Developers\ **Tags:** ifc4, ifc5\ **Created:** [July 31, 2019, 2:55pm UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639 "2019-07-31T14:55:25Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ReD\_CoDE](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/red_code/32/226_2.png) [@ReD\_CoDE](https://forums.buildingsmart.org/u/ReD_CoDE)\ **Post date:** [July 31, 2019, 2:55pm UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639/1 "2019-07-31T14:55:25Z")
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](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/1X/f52443e57ff5eee15980573ff190c04169158fa6.jpeg) 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** ---
**Author:** ![ReD\_CoDE](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/red_code/32/226_2.png) [@ReD\_CoDE](https://forums.buildingsmart.org/u/ReD_CoDE)\ **Post date:** [July 31, 2019, 9:21pm UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639/2 "2019-07-31T21:21:57Z")
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)](https://en.wikipedia.org/wiki/Industry_Foundation_Classes) ---
**Author:** ![ReD\_CoDE](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/red_code/32/226_2.png) [@ReD\_CoDE](https://forums.buildingsmart.org/u/ReD_CoDE)\ **Post date:** [August 1, 2019, 12:11pm UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639/3 "2019-08-01T12:11:20Z")
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` ---
**Author:** ![Barbosa](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/barbosa/32/560_2.png) [@Barbosa](https://forums.buildingsmart.org/u/Barbosa)\ **Post date:** [August 30, 2019, 10:35pm UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639/4 "2019-08-30T22:35:22Z")
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. ---
**Author:** ![ReD\_CoDE](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/red_code/32/226_2.png) [@ReD\_CoDE](https://forums.buildingsmart.org/u/ReD_CoDE)\ **Post date:** [August 31, 2019, 1:43am UTC](https://forums.buildingsmart.org/t/ifc-and-taxonomies/1639/5 "2019-08-31T01:43:38Z")
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