Is not the real problem that the IfcRoad, IfcRail, etc. were all developed differently? and therefore not actually Aligned?
Wouldn’t it be better to fix this major issue, and then STANDARDISE the needed MVDs as ISO Standards versus availability and responsibility solely on bSI?
@ReD_CoDE That modularization of the schema already exists.
@DrShawnOKeeffe While they may have been developed by different teams of people, they should still adhere to the same semantics and general hierarchical constructs.
The problem lies in how the numerous extensions have:
As an example, ponder the following questions:
If the IFC Bridge and IFC Rail have created new structural elements (or permutations of structural elements), shouldn’t the existing “building/architecture” and “structural” domains be reconsidered and have more classes moved into the “common” or “interoperability” layer and then those existing domains, as well as the new “bridge”, “rail”, “road”, and etc., being further specialized, containing fewer classes, so as to avoid duplication/overlapping? If so, then what do those look like?
With the explosion of more applications used across a wide variety of hardware platforms and operating systems (including mobile/web-based), how can we look at the refactoring or (re)modularization of geometry in the schema to better support consistent, reliable results in the variety of implementations across a growing number of workflows? For example, should we have a basic, common BREP geometry “module”, and an advanced CSG/parametric “module”, where either (or both) can be specified for use in an MVD?
This then impacts implementations by doing the following:
Application developers can decide which process/functional domains they want to support (architectural, structural, infrastructure, etc.) for internal data modeling and export (importing applications would assume to support representation of ALL domain classes fro viewing);
Application developers would also decide if they were to support the import/export of BREP and/or CSG/parametric geometries associated with those domains;
Software certification would be based on unit testing an entire domain, or combination of domains, based on their pursuant workflows (building design vs. railway design vs. underground utility design vs. structural analysis vs. mobile device viewing app vs. …). So an example might be Vectorworks Architect certifying on full EXPORT of the architectural/building and site/landscape domains, including CSG/parametric and BREP geometries, but only certify for BREP IMPORT of MEP/building services, while BIMTrack would certify on IMPORT of all domains using BREP geometry but SOLIBRI might certify on IMPORT of all domains and ALL geometric representations;
When application developers certify across the entire range of a domain or module, then MVD creators can have confidence that the applications will support any new MVDs very quickly and not require a ton of time and resources to create support for the new MVD, which varies from previous MVDs.
MVD developers could then better address software functionality and supported workflows by making decisions on more precise or more flexible scopes of included concepts. As an example, a more “general” Design Transfer View, where CSG and parametrics are ALWAYS included and BREPs are optional where advanced geometry cannot be created, can be specified versus a stricter Architecture to Structural DTV where CSG must be used and BREPs are forbidden. (a rough, example, I know, but I hope you get the point);
MVD developers can also create more MVDs outside of having certifications for every single MVD, especially at the international level, and can be more fluid/flexible in creating MVDs for specific market needs without significantly impacting the needs of all other markets.
Potentially, MVDs can become more fluid and be developed on an “as needed” basis, where BIM authoring software gives end users interfaces to create a new, job/process/application-specific MVDs “on-the-fly”, relying on the public information of the receiving application(s) to be able to accurately consume the new model. And, MVDs could be pull as much as push, so the MVD concept might originate as a request from an application (Revit users asks Tekla user for all structural steel columns and ONLY structural steel columns, using CSG or BREP, but no parametrics to use for referencing).
I think the missing part is “I TALK ABOUT SYSTEMS”
Current IFC has developed based on which ontology? Yes you explained it on Wikipedia
I talk about this hierarchical tree:
https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/inheritance-general-usage.htm
This hierarchical design maybe was good for “just BIM” but won’t handle a huge area as GIS+BIM+SomewhatPLM
Even STEP/EXPRESS (ISO 10303-239) today suggests some parts of the idea I shared:
Data Exchange Specification s (DEXs)
Reusable components (Template s)
Reference Data Library (RDL)
Model Usage Guide documents
Based on RDLs and SysML Modeling
So, I suggest to break this long and deep hierarchical tree and build it as “specific packages as Modules”
(I think Control+Product+Process extensions are not good choices for schema architecture, instead Systems → Elements → Parts are
In Systems Engineering “Control+Product+Process” are “Elements and Parts”
And I think current IFC with SE view has this architecture: Just Element → Part
The missing part is dividing schema based on “SYSTEMS”)
Yes, here all “Modules” are decoupled “on paper” but IFC schema as a whole does support this structure?
This is why I suggest:
Decoupling the whole schema on modules as systems/disciplines and core modules
Then you can build:
Concept Usage + Module Usage matrixes and Concept Usage + Entity Usage matrixes
Also please see these two as well:
What about standardising MVD under ISO, e.g. similar to ISO 10303 Parts for STEP…We could have ISO 16739 Parts for Information Exchanges?
Parts 1-100 for buildings, 101-200 Roads, and so on…
Q: “Do we define different levels of implementations (easy geometry; advanced geometry; parametric import; etc)?”
A:
1.
Yes, levels of implementations meaning the application software (ASW) support of standardised feature sets
Dinstinguish between IFC IMPORT and EXPORT capabilities of ASW products
for e.g. representation paradigms (Primitive instancing, CSG, Sweep volumes, B-rep, see https://3d.bk.tudelft.nl/projects/geobim-benchmark/ifc.html)
For CDE-ASW interoperability add transactional and roundtrip capabilities
roundtrip capabilities for instance address “conservative IFC processing” as the abiity of an ASW product to back-deliver an almost UNCHANGED IFC to the CDE if NO design step has been performed:
roundtrip : CDE > IFC (checked out) > ASW (immediate IFC export after IFC import without any design step) > IFC (to be checked in) > CDE
4.a
Parameterizable generic product definitions enabled by {expression} instead of constant attribute value (again distinguish capability at IMPORT / EXPORT):
4.b
Parameterizable generic building definitions enabled by {expression} instead of constant attribute value:
Q: “How do we make the (interoperability layer) schema more strict?”
A:
Align and judge the universality of the schema based on REAL LIFE
ENABLER are:
IFC schema also provides features for applying restrictions by following RESTRICTORS:
Q1: What are the borders between modules?
Q2: How does the release cycle look?
A:
I don’t have an specific answer because I don’t have demand for or advantage from modularisation.
Therefore I provide a very general comment only:
Identify stakeholder group(s) who have considerable demand for or advantage from modularisation.
Is this Software-Industry only? Are there other stakeholder groups demanding modularisation?
Ask each stakeholder group for a consolidated answer on the two questions Q1, Q2
Try to align the stakeholder groups
If no alingment is possible think about modularisation on two or more dimensions (speparate dimension for each stakeholder group => modularisation matrix (2D) / modularisation cube (3D)
For better understanding could you please provide more background information and some simple examples on your slide “Extending further” ?
Especially the statements “Current subject entries are ‘subjective’ and polarise bSDD and IFC” is unclear to me as well as the statement “Need to introduce ‘indication of connectivity’”
What ist the “connectivity concept” about?
Where can I read more about this statements and concepts?
(please provide some links to scientific papers or articles, if possible)
Thx
@nn1 (your first reply)
Yes,
@Moult (your first reply)
Your statement “BIM authoring tools that focus on aspects of the IFC schema.”
I aggree on that idea.
It is somehow similar to the (old but good) concept of microservices where specialiced tiny applications perform operations on common data (e.g. via open API interface of CDE).
This has some similarities to the MVC (Model View Control) concept as well:
