Thank you for your answer. yes, I also suspect that the key point is the way the models are structured. We often have the situation that three models have the same elements in play: architecture, engineer and entrepreneur (timber construction). all three create models with very different goals. The architect coordinates the requirements, the civil engineer calculates the statics, the entrepreneur optimizes the elements in terms of logistics and efficiency. At the end, the builder would like a fourth model, as was actually built.
If the IFC models are at least modeled according to standard and structured according to a common classification, the information can be checked visually with filter.
Our biggest problem (in Switzerland and Germany) at the moment is that not everyone involved is able to manufacture IFC according to the standard. We often cannot trust our own data.
who knows, maybe these processes will be simplified in the future by new technologies. I suspect, however, that the model has to be built with a consistent structure for a long time, since the model represents the source of the data.
This is just an interpretation of what we can read from the specification.
As it considers the Pset_ a prefix we could use it in the middle of the string, as many of us do with the aim to distinguish it from the Software OOTB Pset (mostly with any reference to the acronym Pset in their desriptions, except some cases (i.e. Graphisoft Archicad: AC_Pset_RenovationAndPhasing)
Is the uncoordinated emergence of arbitrary defined properties the result of an inadequate consensus about modelling principles and a lack of standardization?
Will the new bS technical roadmap address this lack of standardization?
I think not all of the issues/challenges, but most of them are solvable:
Some months ago bSI friends mentioned that they think about âUML/SysMLâ which âIFâ this happens which Iâm not sure, because STEP traditionally prefers EXPRESS-G, will improve this area a lot
STEP AP 242 as I mentioned before can help bSI to solve most of the challenges but still not all of them (especially related to Geometry/Topology, âŚ)
Modelica which is part of the answer related to Formal Analysis, Simulation, and Emulation which bSI has worked and works with Modelica-related groups
CDE which bSI thinks about OpenCDE which is another topic and the vitally important part is here, especially related to âTRACTABILITYâ
If I may give a suggestion to the OP, until a solution is found within BS.
Prefix Pset, is according to your need, switched to something like: Req_ for Required AsB_ for As Built (if you need to document it, otherwise Iâd leave it). Add_ for anything extra you may add, outside of established Psets by BS, Client, x.
Add Req and AsB as suffix to parameters, where they have a equivalent BS *Common one.
This is how I recommend it in Denmark, and similar syntax for requirements, is widely used in Norway.
While not perfect, itâs functional today. And naturally, many other methods could be used, nor problem. Just make sure that you document the one you pick.
Yes, you can do it in this way, but this does not make a sense - âPsetâ is just an acronym of âProperty setâ, so I prefer to make my names shorter than to add âPsetâ-additional part of these names. This is quite enough to use âStakeHolderAcronym_Descriptionâ, without âPsetâ in the middle. Why GRAPHISOFT use such syntax - this is their deal and this is not an ideal.
Me, personally, just careful read what is written in the description of IfcPropertySet, agree with it and follow by this convention. From my experience, all cases when vendors, users or consulting companies used âPsetâ were by the reason that they didnât read this statement.
================================
IfcPropertySet:
5.1.3.14.1 Semantic definitions at the entity Entity definition
The IfcPropertySet is a container that holds properties within a property tree. These properties are interpreted according to their name attribute. Each individual property has a significant name string. Some property sets are included in the specification of this standard and have a predefined set of properties indicated by assigning a significant name. These property sets are listed under âproperty setsâ within this specification. Property sets applicable to certain objects are listed in the object specification. The naming convention âPset_Xxxâ applies to all those property sets that are defined as part of this specification and it shall be used as the value of the Name attribute.
In addition any user defined property set can be captured. Property sets that are not declared as part of the IFC specification shall have a Name value not including the âPset_â prefix.
From a characterâs number economy standpoint, yes.
But in my opinion, there are too many software vendor-generated property sets with any consistent cross naming convention. That is why, when we generate company sets of properties we like to include the middle-sufix âPsetâ which helps us to distinguish them among so much garbageâŚ
Doing that, we donât dissent from what is specified in the Schema. As I said previously, Prefix is not a middle Acronym . Otherwise, we should ask to update the Schema definition including that âPsetâ shall not be used in any part of the description (Prefix, sufix, middle-sufixâŚetc).
@daviddelven⌠For certification, and general IFC implementation guidance, ANY custom property sets should NOT start with the prefix âPset_â so as to make it clear that they are custom and not part of the schema. Any vendor doing otherwise is working against what I thought had been recognized as a simple implementation consensus.
Problem: many BIM software generate psets with arbitrary names in an effort to get out user data. This data is mostly unvetted and inconsistent. Or âgarbageâ as he puts it.
Solution: he wants to distinguish his company standard vetted psets from the auto-generated âgarbageâ. To do this, he inserts âPset_â in the middle. E.g. âABC_Pset_Fooâ.
I see this as a good solution.
Iâd like to add that I have come across BIM vendors outputting official psets (i.e. those starting with Pset_) with incorrectly named or extra properties. I hope these would be caught in the IFC4 certification process.
