Decoupling Model and Data/Information (IFC & ISO 19650)

[ReD_CoDE]

Would be happy to know your view about separating the model and its data/information and join data/information to the model based on tasks/“information need”

For instance, for AIM or FIM, companies will provide a highly detailed model (Reference Model) with “appropriate data/information for asset management or facility management mounted or integrated to the model”

I mean in the near future we will have some MVDs for “models” and some MVDs for “Data/Information” completely separate but can merged anytime needed

Model MVD/DTV (DTs) + Data/Information MVD/DTV (DTs)

A Reference Model that can generate “Micro-Models” based on
And some data/information “templates, Psets” that can be integrated and merged to model based on task/information need/scenario

For instance for Energy Simulation, the Micro-Model generated based on the Reference Model can represent just boundaries and some other geometric/topologic/analytic models needed
And appropriate Data/Information needed can be integrated through templates/Psets

It will cause file size reduction and avoid reputation and improve performance

[klaus.aengenvoort]

The decoupling of the visual representation and the alphanumeric information in models can be done. We have realized an approach for facilities management, in just using data templates and data sheets within IFC.

Another way is, to exchange product data separate from the visual representation of the product. We are working on a model view definiton so called “Product Data View” (PDV):

buildingSMART/ProductData

It is not ready yet, but looks promising though.

These approaches will allow it, to exchange parts of models, and re-attach the information to existing or new visual representations.

[Moult]

@ReD_CoDE what you have described can already be done, and in fact is already done in Blender BIM.

Geometry, BIM objects, and properties are completely decoupled.

[gester]

maybe i’m missing some vital information, but what is the point in decoupling the alphanumeric data from the geometry model beside file size? i’ve always assumed that 5g would allow for any data size, let alone zipped ifc or bcf, which are actually peanuts compared with the native files…

[Moult]

The advantages are as follows:

• Filesize, as you have mentioned.
• They can be worked on in parallel - disciplines can independently develop certain BIM data (such as an FM team working on asset data while the modeling team is working on geometric shapes)
• Not only can they be worked on in parallel, they can work without the other one existing to be plugged in later.
• They can be reduced to smaller ASCII files which can be version controlled using tried and proven versioning systems such as Git / Hg / P4. We will no longer be locked into cloud platforms such as BIM 360 which deal with monolithic files and implement version control in a very poor way.
• Files can be kept as ASCII instead of encouraging teams to use binary due to file efficiencies - this means that BIM models will never become corrupt. For example, in the film industry, it is standard practice to decouple related data and as a result manageably store everything in ASCII to prevent data corruption. The construction industry will follow, I expect.
• They can be analysed separately for efficiency. When files are updated in a BIM server, just the relevant files can be parsed for automatic analysis, such as for automatic environmental analysis, costing, or health and safety constraint metrics. For example, a Blender BIM costing export takes a split second and can be read / written / parsed headlessly also in a split second.
• It means that the IFC spec can evolve in a reliable way. Mixing keywords into less but highly coupled keywords means that the spec cannot keep the base classes stable whilst experimenting on newer data classes.
• It means that authoring programs can focus on only delivering parts of the IFC that they specialise in. There will no longer be need for full IFC / BuildingSMART certification, if all a program does is specialise in generating IfcShapeRepresentation, for example, which can be plugged into other IFC programs. This means a greater ecosystem of tools, more interoperability, and less monopoly behaviour.

There are probably more advantages that I missed.

[gester]

@Moult
many valid points, thanks.

1. i’ve never considered a native platform like bim 360 as a viable solution for bim level 3, though.
2. i can get the notion of the managemenet of those two entities separately, but it’d be a double management, right? is there no danger of disintegration of created information (log + loi) in the maintenance and delivery?
   i presume such apps as simplebim would be obsolete then…
3. bim authoring applications create both data types (geometry and text information), so it wouldn’t make much difference if some chunks of both would be missing, designers would have to provide their ‘coupled’ data, wouldn’t they?

a bit devil’s advocate, but anyway

[ReD_CoDE]

Thank you @klaus.aengenvoort,
I’m familiar with PDT and PDS and I was guessed about PDV too. However, all of these are focused on “Data/Information” side

The idea I have in mind is that we separate “Geometry” which I call “Model” because of some reasons from “Data/Information”
And “Geometry” has a “Level of Detail - LoD generator” that can generate lot of Models with different LoDs based on scenarios and tasks based on “Level of Information Need - LoIN”

Also the same scenario for “Data/Information” with specified templates/Psets through “Level of Information - LoI generator”

Then companies based on “Level of Information Need - LoIN” agree that for example “Handover” should have this LoD and this LoI and then the authoring tool like BlenderBIM generates these different LoD and LoI and if needed merge them and produce one file that has Geometry and Data/Information

And the information system has the ability to "store Models and Templates/Psets for multiple uses in future projects too"

I think it could be a “Collaboration Information System” when the whole network work together and produce multiple-use contennt"

@Moult I have a good feeling to BlenderBIM, as I mentioned it has a lot of potentials to be an invaluable authoring tool

[gester]

thank you, ehsan, you’ve got the point: different levels of log (level of geometry - i like this name bias i’ve seen in one swiss presentation) and loi for the particular project stage
this is reason enough for me.

[ReD_CoDE]

Thank Robert, for me simplicity and performance of the information system I dream is important.
And all together will work hand in hand to bring it to reality

[ReD_CoDE]

Two of the commonly known MVDs that are officially approved by buildingSMART are the references view (RV) and design transfer view (DTV) (bSI, 2015b, bSI, 2015a). The RV is defined as a subset of the IFC4 schema that comprises a set of MVDs for reference workflows such as iterative design review and coordination in BIM projects. The RV can represent geometry and properties as read-only: that is, RV users can extract data from RVs, but cannot edit them. On the contrary, as an extension of the IFC4 RV, the IFC4 DTV supports handover workflows and allows editing, such as inserting, deleting, and modifying DTVs. Some use-cases of RV include background reference, coordination planning, clash detection, and visualization. Those of DTV include takeover or import data from a previous design. The scope of DTV is larger than that of RV; in other words, the RV is considered a subset of DTV. In addition, other MVDs, such as coordination view, structural analysis view, and basic FM handover view (East et al., 2013), are still in development. More model views being developed by other organizations can be found on the IFC Solution Factory website (buildingSMART, 2005).

Reference: Kahyun Jeon & Ghang Lee @glee , Information Delivery Manual (IDM) Configurator: Previous Efforts and Future Work

Imagine you have a rare pot, for example, an old Chinese pot, which just few of them exist in the world, so how you check if those are original or fake?
You compare them with the original one you have, if are the same you say they are original, otherwise are fake

I think my proposed idea is so close to RVs and DTVs (DTs) but with the difference that we have some “globalized RVs and DTVs” as international references that represent:

1. Globalized Reference Views - GRVs

• Material (Material Bank, IFC-based materials with advanced colors and textures) --> An .org domain for Material Bank reserved
• Product (Product Bank, IFC-based products with advanced materials) --> An .org domain for Product Bank reserved
• Other Globalized Reference Views

2. Globalized Design Transfers - GDTs

Also, Globalized Design Transfers as references which generated once globally and can be used multiple times in local projects

For instance, a globalized schedule document, or a globalized legal document which accepted as a reference for all countries as a base and can be developed/improved based on local needs

And all the Globalized resources flattened as well as decoupled as “Models” and “Data/Information Templates/Psets” for multiple-use resources to generate GRVs and GDTs as you see in the aforementioned picture

This will reduce costs, and repetitions and will increase trustworthy and accuracy and less legal issues in the projects