Use consistent GUID's for the same properties that are used in different PSets

[klacol]

For historic reasons for a long time, a property that had been assigned to more than one property set has got different ifd guids. I.e., the property "ThermalTransmittance" assigned to PSet wall-common has a different guid as the property "ThermalTransmittance" assigned to pset slab-common - despite the fact, that it is the same property. Hence there are many instances of "ThermalTransmittance" in bSDD and in IFC - which is wrong.

All instances of "ThermalTransmittance" in bSDD and in the IFC PSet files should have the same and constistent GUID.

[stefkeB]

Isn't this a bit in conflict with the impression that Pset_WallCommon.ThermalTransmittance and PSet_DoorCommon.Thermaltransmittance are not seen as the same? Or are they both instances of the unique property or characteristic "thermal transmittance" (the way the user perceives it)?

Is any property name in whatever property set it resides in by definition unique or can it indeed be shared among property sets (and thus needs to be identical)? Is this in line with the way properties are managed and measured? (Probably discussion for CEN/TC 442/WG4)

They currently seem to be defined always in the context of a property set. However, if they are indeed unique, you don't need the property set anymore or the propertyset is only a convenience of grouping (comparable to a Tag).

I don't have a "right" answer to this question, but it needs to be resolved somehow

[TLiebich]

this is a well known and recognised issue - it needs to be addressed by making each property (having the same name) unique within the scope of the ifc specification, and not only within a single psets. Hence those properties, like ThermalTransmittance, have to have a single GUID. Inprovements of ifcDoc are currently developed to ensure that this is fixed.

[klacol]

They currently seem to be defined always in the context of a property set. However, if they are indeed unique, you don't need the property set anymore or the propertyset is only a convenience of grouping (comparable to a Tag).

I like the comparison of a PSet to a "Tag".

One Property would have one or many relations to a PSet. There are properties, that are defined globally and others, that are defined on the level of a Property Set. The grouping of properties in a PSet itself is a separate information and has its own ID. So this is a valueable information too. IMHO we need booth, the property and the group of properties (e.g. purpose driven , like a PDT).

[klacol]

I have made a try with a "normalized PSet" that references the included properties.

I have made a copy of the Pset_ActionRequest.YAML into the Pset_ActionRequest_normalized.YAML and created individual properties in the subfolder "Properties".

The three properties are now referenced with this syntax:

$ref: '#/Properties/R/NameOfMyPropertyFile'

This could make it possible to eliminate duplicate properties in different PSets.

[rogerjgrant]

Hi Klaus, i hope i am responding to this appropriately and this gets to you as i am not normally responding on GitHub. I was copied on this discussion however and it reminded me that i believe that Tim has addressed the problem of duplicate properties in ifc.Doc so i reached out to Tim and he had this to say: "For compatibility with existing releases and to integrate with GitHub and representations of IFC in programming languages that don’t have any concept of properties being shared across multiple data types, the issue of duplicate properties was solved by introducing intermediate “abstract” property sets that provide the common definitions. Tools can then automatically detect such duplicates by traversing supertypes to find properties having the same name. Two property sets were introduced that capture most of the duplicate properties: Pset_ElementCommon Reference Status Pset_BuidingElementCommon IsExternal LoadBearing FireRating ThermalTransmittance There may have been others; those are the main ones that I recall. As was discussed before, just because two properties have the same name doesn’t mean they are the same thing – sometimes naming is done for consistency but the definitions are specific to where they are defined." I will also add that Tim has just successfully been able to upload IFC4.1 directly from ifc.Doc to bSDD following through on a project we have been working on for some time to establish a direct connection between ifc.Doc and bSDD. After clearing up some bSDD issues, we have been able to complete what appears to be a successful upload of IFC4.1 to a clean bSDD test site. We are reviewing this now. If you are interested i can get you a link to review it. Expect that we will discuss further in Dusseldorf to the extent that we can. And certainly need to coordinate on the process for using the ifc.Doc to bSDD connection to publish the "official" IFC version in bSDD. We are not doing that without coordination with bSI (Thomas, Greg, Chi, Sigve). I am copying Tim in case you have any questions or need further clarification. Roger

…

On Fri, Mar 15, 2019 at 12:45 PM Klaus Aengenvoort ***@***.***> wrote: I have made a try with a "normalized PSet" that references the includes properties. I have made a copy of the Pset_ActionRequest.YAML <https://github.com/buildingSMART/bSDD/blob/master/PSets/YAML/Pset_ActionRequest.YAML> into the Pset_ActionRequest_normalized.YAML <https://github.com/buildingSMART/bSDD/blob/master/PSets/YAML/Pset_ActionRequest_normalized.YAML> and created individual Properties in the subfolder "Properties". The three properties are now referenced with this syntax: $ref: '#/Properties/R/RequestSourceLabel' This could make it possible to reduce the duplicate properties in different PSets. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aiottqpdf-ovAYVoKZ-OVYo2EROnUDSBks5vW84agaJpZM4YmRKi> .

[klacol]

Hi Roger, thanks for your Feedback.

The question is: "What are same properties?"

I think, when the following information about a property is identical, then a property can be seen as identical and they can be merged onto one GUID:

Name
Definition
DataType
MeasureType

For the properties, you have listed, these information is identical und these properties can be normalized and merged.

In the YAML-proposal, I have added in addition in the relation of the PSet to the normalized property the "usage_definition". That could help to further define the normalized property in the context of the PSet.

In the IfcDoc-Group alre parallel discussions about the same topic, @TLiebich and @timchipman are also involved. We should speak about that in Düsseldorf.

[TLiebich]

Hi all, cc: to Jon, who is actively working on it as well. Previous status of ifcDoc had been, that the proposed solution from Tim only worked as a work around. It did not prevent having duplicated guid's in export. And it did solve the source of the problem, that properties should be referenced in psets and not owned by psets. We now have a plan and a partially implemented solution, a few more tests are needed however. But when are two properties are identical: as Klaus said, if the have same name, description, type and measure. Those properties can be collapsed automatically. This already is a big step. Next group has same name, type and measure. But slightly different descriptions. E.g. Fire resistance of a door / fire resistance of a window, instead of fire resistance of an element. Here we have three options, to be decided by humans, a) it is the same, the description can be unified b) it is the same, but it is beneficial to have a usage description (how to use the property in the context of the pset/element) c) it is not the same, then they should have different names and then there are properties with same name and type but different measure. Those should be checked if the different measures are intentional or not and fixed accordingly, either unify measure or have different names. We are now in the process of making the QA process for IFC psets and the result should be updated to bSDD. Regards Thomas -- Dr. Thomas Liebich AEC3 Deutschland GmbH Geschäftsführer / Director Am 20. März 2019 08:51:35 MEZ schrieb Klaus Aengenvoort <notifications@github.com>:

…

Hi Roger, thanks for your Feedback. > > The question is: "What are same properties?"> > I think, when the following information about a property is identical, then a property can be seen as identical and they can be merged onto one GUID:> > Name> Definition> DataType> MeasureType> > For the properties, you have listed, these information is identical und these properties can be normalized and merged.> > In the YAML-proposal, I have added in addition in the relation of the PSet to the normalized property the "usage_definition". That could help to further define the normalized property in the context of the PSet.> > In the IfcDoc-Group alre parallel discussions about the same topic, @TLiebich and @timchipman are also involved. We should speak about that in Düsseldorf.> > -- > You are receiving this because you were mentioned.> Reply to this email directly or view it on GitHub:> #5 (comment)

[atomczak]

resolved in IFC itself (as well as bSDD)