Transactional Exchanges

[SergejMuhic]

One discussion I would like to open regarding this topic is a request protocol for querying data. An efficient way would be to standardize the pulling of data through a protocol. Probably mvdxml could serve as a basis. In essence, send your request e.g. as an mvdxml and get the data back (whether SPF, XML, JSON or any other format). It is probably a complementary method to APIs as it would also support complete file exchange.

Currently, everyone has to setup their IFC export in their tool whether it be Archicad, Revit, Allplan etc. instead of the receiver defining what they want and send a standardized request to the tool generating the data.

[berlotti]

There are many solutions for querying and filtering IFC on request. The technical roadmap (hopefully public soon) identified that we need a new 'Exchange Information Requirements' that can serve for this purpose. The big issue in IFC that needs to be solved are the references and dependencies. When querying an object in IFC, there are many other objects that need to be transported to be able to get all the information. For example, an IfcWall probably also needs the referring ifcOpenings, the ifcMaterial, the propertysets, etc. The positioning of the wall is depending on relative coordinates to each other, and probably the ifcSite, ifcBuilding and ifcProject are also needed. These references need to be discussed in the core of IFC before we can create transactional exchanges effectively.

[pipauwel]

The presence of exactly 1 IfcProject instance is currently required for the IFC file to be valid. Many other things are required for IFC content to be valid (cfr. @berlotti's comment). This prohibits this kind of transactional exchanges through valid IFC. For example, you can't exchange a simple wall and its properties, because that is technically invalid IFC without the entire project and so on (regardless of MvdXmL).

I suggest to reduce the number of 'required' constraints (I would only keep GlobalId, Name and Class as required attributes), in order to promote this kind of transactional exchanges.

We need to enable this - without all other IFC required material:

{
  "Class": "IfcWallStandardCase",
  "Name": "Wall xyz",
  "Description": "Description of Wall",
  "GlobalId": "fc844dd2-f71a-4a85-8010-8cd7154504a7",
  "Volume": 181698.20138837994,
  "Combustible": false,
  "ThermalTransmittance": 0.24,
  "IsExternal": true,
  "ExtendToStructure": false,
  "LoadBearing": false,
  "Compartmentation": false
}

[jwouellette]

While all previous "contraints" (references, dependencies) or the perceived arbitrary IA requirements should be reevaluated, I think that context for such constraints do matter and depend on the workflow. For some transactions, relationships and constraints may be superfluous, but other workflows (data validation/analysis) may benefit from or rely on them. Again, maybe it is a matter of rules that are more dependent on the serialization than on the schema.

[pipauwel]

Agree. There are workflows that require constraints (e.g. full file exchange - main IFC workflow today). But well... they currently prohibit other workflows, for no real reason? Can we have a double track IFC (full file exchange with constraints everywhere for validation purposes + transactional IFC snippets)? Or is it an active choice to not allow transactional exchange and focus on full exchange? Or do we relax the schema at least a bit more to allow at least some transactional exchange?

That seems to be a choice to be made as part of a next gen IFC technical strategy at least.

[berlotti]

This choice is already made. See https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC

This is the whole reason we are gathering these issues.

[SergejMuhic]

"There are many solutions for querying and filtering IFC on request." - Spot on i.e. not standardized.

Would also like to add that it is not so much about queries of IFC, it is about getting only what you want, when you want it without developing an MVD for all possible use cases. Pulling data instead of pushing. This could be done independent of the queried platform. The transferred data, of course, would have to be structured in a standardized manner but for that there are solutions, as mentioned in STEP, JSON, XML, schemas would have to be adjusted as @pipauwel mentioned. What I am missing is a standardized request (analog to BCF for issues).

[klacol]

The presence of exactly 1 IfcProject instance is currently required for the IFC file to be valid.

Is this an requirement of the base schema, or of an model view? In the upcoming standard for the exchanges of constructions objects we are planning to have structures that just contain a IfcProjectLibrary. Perhaps I have overseen something?

[pipauwel]

Topic seems to be in conclusion already. Yet, to respond to @klacol:

This is in the base schema of IFC, last few lines in https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/EXPRESS/IFC4.exp

RULE IfcSingleProjectInstance FOR
    (IfcProject);

    WHERE
      WR1 : SIZEOF(IfcProject) <= 1;
END_RULE;

I have no idea whether or not this is an obstacle in a model view; yet, I think that the idea of MVDs has always been that it should still result in a valid IFC file. And then this becomes an issue, indeed. A small one.

[klacol]

Thanks @pipauwel : All my files have been valid in XML Spy, but the tools "only" validates against the XML schema (the XSD). This is one point PRO WHERE RULES (see #39).

[TLiebich]

the reason for the rule is, that a "normal" IFC file is only complete and self-sufficient, if the context with units and measure types is declared. I.e. that the receiver knows, that a length unit is actually measured in m, or mm, or inch. While theoretically it could be zero (in case, all units are declared locally and no geometry is used, it cannot be >1 to avoid having redundancies, i.e. lenght unit declared twice as m and cm.

However it is indeed a bug, that can easily be corrected, when replacing IfcProject with IfcContext (obviously the rule was not updated, when IfcContext got added as supertype of IfcProject in IFC4).

RULE IfcSingleContextInstance FOR
    (IfcContext);
    WHERE
      WR1 : SIZEOF(IfcContext) <= 1;
END_RULE;

[SergejMuhic]

Is this a case for WHERE rules? I think it is. Some things can be handled by defining requirements but others, such as units, coordinate system origin etc. are common rules for any exchange. First, the requester should not have to think about that and second as it is common for any exchange it should be handled in the data model itself.

[berlotti]

WHERE rules only exist in EXPRESS. We need to make IFC language independent. Some kind of restriction could be a solution here, but WHERE rules only apply to the STEP serialization. This is why it was decided to find another solution for restrictions on the schema (#39 )

On a side note: The ISG questionnaire in 2019 and the latest ISG meeting in 2020 have learned us that vendors do not parse WHERE rules during import and export. During export this hinders the export when users didn't model correctly (which is not desirable), and during import it does not add real value for end-users.

[SergejMuhic]

Some kind of restriction

Seems reasonable yes. Some basics such as where units are defined, where the coordinate origin of the project is etc. should not be defined over and over but have a rule in the spec/schema. Should be machine readable though. Those formal propositions in documentation are harder to consider.