In general: where are requirements mapped in the IFC?

Users
#21

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.

Best regards

#22

Hello, Alexey.

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)

“StakeHolderAcronym_Pset_Description”

Regards,

David

#23

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?

#24

I think not all of the issues/challenges, but most of them are solvable:

  1. 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
  2. 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, …)
  3. Modelica which is part of the answer related to Formal Analysis, Simulation, and Emulation which bSI has worked and works with Modelica-related groups
  4. CDE which bSI thinks about OpenCDE which is another topic and the vitally important part is here, especially related to “TRACTABILITY”
#25

@Herb Hopefully, yes.

1 Like
#26

Which one you prefer? The approach IfcDoc follows, or the approach IfcXtreme suggest which is node-base?

#27

I do not know both of them. But do use nodes may be easier for endusers as me.

#28

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.

Req_DoorCommon - FireRatingReq
AsB_DoorCommon - FireRatingAsB
Add_DoorCommon - HasFunctionX

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.

2 Likes
#29

Thank you @Brunner

@tsolsen I think what you suggest with some improvement could be better than Pset_ when it’s general and doesn’t specify things well

Req_
AsD_ (As-Design)
AsB_ (As-Built)
Add_
etc

#30

@berlotti Hi Leon, according to Issue #41 (https://github.com/buildingSMART/NextGen-IFC/issues/41)

I think this can help you think better about Psets and Qsets:

Hope this help with

#31

Hello, David,

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.

(https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/schema/ifckernel/lexical/ifcpropertyset.htm)

===========================

Regards,
Alexey

#32

Hello, ADavydov

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).

#33

@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.

1 Like
#34

@jwouellette My interpretation of @daviddelven’s approach was:

  1. 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.
  2. 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.

1 Like
#35

@Moult Thanks for summarizing it, so clearly. :wink: