Maintain the official PSets and their localizations

[klacol]

Based on resolutions by the Technical Room and the Product Room on the summits in Paris and Tokyo, the official PSets will be maintained by the ProductRoom within the bSDD. The PSets stay an official extension of IFC.

The plan is, that the chapters can contribute their localization of the PSets in a GitHub based workflow as follows:

• The chapter makes a fork of this repository
• The chapter commits the localized PSets into the fork
• The chapter makes a pull request
• Members of the Product Room and the Technical Rooms check the pull request
• If the pull request was done according to the quality guidelines they can approve the pull request
• The new approved localizations will be automatically transfered to the bSDD at http://bsdd.buildingsmart.org
• The Product Room and the Technical Rooms say "Thank you" to the contribution chapter

In this issue we plan and describe this workflow in detail. It is clear, that the first steps can be try and error. Every hint and contribution is welcome.

[klacol]

A preview of the transformed PSets in YAML can be seen here, in my private repo for PSets.

I am in the process of comparing the GUids in the official PSets files and the corresponding Guids in the bSDD. By clicking on the badge, a log file is shown, where the result of the comparison can be seen.

Some Guids are identical but most are not.

I will make the GUID's now identical and then move the PSets into this repo here. I will take the GUID from the bSDD and store it in the PSet files. I would conserve the old GUID in the PSet as well, so people can transform them, if someone has ever used the Guids within the PSet files (see also the discussion about that between @timchipman and me here)

[TLiebich]

comment #1 - the items in the list are fine, but we need to add another list item:

• The new approved localizations will be automatically transfered to the upcoming IFC publication at www.buildingmart-tech.org/ifc (and finally to https://technical.buildingsmart.org/, once available)

this is to include the quality assured IFC translations in the upcoming IFC releases (using ifcDoc)

[TLiebich]

comment #2 - I am puzzled that the GUID's are not the same (or at least in many cases). There has never been a separate process for assigning individual GUID's to properties following the IFC development process. The GUID's had always been obtained from bSDD. If there is a mismatch, there must be a bug in this process (or the tools, used for it). It would be worthwhile to check (and to prevent it from happening again).

[klacol]

comment no 1 - the items in the list are fine, but we need to add another list item:

• The new approved localizations will be automatically transfered to the upcoming IFC publication at www.buildingmart-tech.org/ifc (and finally to https://technical.buildingsmart.org/, once available)

this is to include the quality assured IFC translations in the upcoming IFC releases (using ifcDoc)

Yes, that is the plan.

[klacol]

comment #2 - I am puzzled that the GUID's are not the same (or at least in many cases). There has never been a separate process for assigning individual GUID's to properties following the IFC development process. The GUID's had always been obtained from bSDD. If there is a mismatch, there must be a bug in this process (or the tools, used for it). It would be worthwhile to check (and to prevent it from happening again).

I am also unsure about this. We have to check that. The different notations of the GUID's in the PSet files (e.g. "04abf900d1c411e1800000215ad4efdf") and in bSDD (e.g. "04g$a0qSGHuO00025QrE$V") make it complicated to compare them. I start first to convert them all into the IFC-Format ("04g$a0qSGHuO00025QrE$V") and then we can see more.

[klacol]

This is the corrected workflow for the localization of the PSets in a GitHub based workflow:

• The chapter makes a fork of this repository
• The chapter commits the localized PSets into the fork
• The chapter makes a pull request
• Members of the Product Room and the Technical Rooms check the pull request
• If the pull request was done according to the quality guidelines they can approve the pull request
• The new approved localizations will be automatically transfered to the bSDD at http://bsdd.buildingsmart.org
• The new approved localizations will be automatically transfered to the upcoming IFC publication at www.buildingmart-tech.org/ifc (and finally to https://technical.buildingsmart.org/, once available)
• The ProductRoom and the TechnicalRoom say "Thank you" to the contributing chapter

[klacol]

I have established a"PSet build". I runs on every pushed commit. The latest build kann be accessed here.

The "PSet build" does this:

• Build the tool "PSet2YamlConverter" and the tool integrated bSDD Client
• Start a script that starts the PSet2YamlConverter.exe for all PSets in /PSets/XML
• Read the PSet (IFC 4, ADD2) from the PSet XML format
• Convert the GUID's from the PSet notation to the IFC notation
• Check, if the GUID is available in bSDD API
• If not, look for PSet and Property in bSDD API by name and retrieve the bSDD-Guid
• Print all infos out in the log
• Save as YAML file with an enhanced scheme
• Save as JSON file with an enhanced scheme

The log shows detailled information about the mapping status of the "File based PSets" and the "bSDD based PSets".

[klacol]

The YAML-PSets and the JSON-PSets in this repo are based on an extended schema. This schema is based on the PSets-Schema, but contains many more classes and properties for PSets and Properties. We will have to speak about this schema and decide, if it suits for the future.

The YAML-PSets and the JSON-PSets in this repo contain now this GUID's:

• ifdGuid: The guid that is resolved by bSDD in the short IFC notation (e.g. "3gkkW0qRmHuO00025QrE$V")
• legacyGuid: The guid from the PSet files (XML) in the "UUID notation without dashes" (e.g. "57735433d37a4372b84c44a53ac146fa")
• legacyGuidAsIfcGlobalId: The guid from the PSets files converted to the short IFC notation (e.g. "1NSrGpqtf3ShXCHAKwmKRw")

The question of the different notation of the GUIDs is discussed also here.

The XML-PSets in this repo are yet unchanged, compared to the published PSets of IFC4, ADD2, TC1.

Numbers:

	PSets	Properties
Sum	436	2706
resolved guids in bSDD	24	15
not resolved guids in bSDD	412	2691

If we decide to go on, the not resolved guids would change in the new YAML-based PSets. This would be the base for installing the workflow for the localizations.

[rogerjgrant]

Thomas and Klaus, I have a question about the transfer of the PSet localizations to the IFC documentation. Is the comment by Thomas saying that the localizations should appear in the doc tool? Or would it be better to only link back to the bSDD to access the translations and keep the doc tool with only the english language? If there are a number of translations made, this could make the doc tool UI very cluttered. Perhaps if there is a way to select a language to display in the doc tool this could be useful but to just display all translations seems problematic to users unless they could be filtered. Thoughts? Should we include Tim in this discussion?

[klacol]

Roger, I think, the IfcDoc Tool uses the PSets and their localizations as one source among others to produce the HTML documentation and the MVD's.

As I am working on having the PSet-files and the bSDD-PSets links with the appropriate GUID, they both will contain the same content. IfcDoc could take the one, that is easier for the tool.

It would be helpful, if Tim would explain, how the (localized) PSets can be integrated in the workflow of IfcDoc, so that we can start to design a complete picture of the workflow, including the contribution of localizations (e.g. the upcoming german, russian and spanish localizations).

[klacol]

Today I have added another representation of the PSets in the format of RESX files (ressource files). These ressource files can easily be used to support localization workflows. RESX is an industry standard for storing and editing texts in different languages.

I have tested them succesfully with the tool ResXResourceManager. We can see now all existing and missing localizations in columns next to each others.

This looks like this:

Chapters can choose an appropriate workflow, based on their technical expertise:

1. They can edit manually or programmatically in the PSet-files and contribute into this repository
2. They can edit the RESX-files and rely on a wide toolset (e.g. an RESX editor like ResXResourceManager) and contribute the RESX files into this repository.

Then, we would transport the approved results automatically to bSDD and IfcDoc.

[TLiebich]

Thomas and Klaus, I have a question about the transfer of the PSet localizations to the IFC documentation. Is the comment by Thomas saying that the localizations should appear in the doc tool? Or would it be better to only link back to the bSDD to access the translations and keep the doc tool with only the english language? If there are a number of translations made, this could make the doc tool UI very cluttered. Perhaps if there is a way to select a language to display in the doc tool this could be useful but to just display all translations seems problematic to users unless they could be filtered. Thoughts? Should we include Tim in this discussion?

My thought was about ensuring that the translations are readable by ifcDoc when a new release of IFC is published. The IFC publication (which also reflects a snapshot of the agreed property definitions at the time of publication) need to contain the translation. The ifcDoc tool itself does not have to store them independently if those can be retrieved reliably from the dictionary (or directly from GIT) during the build of the documentation.

[jmirtsch]

Hi Klaus,
Where did you source the xml files for https://github.com/klacol/PSets/blob/master/XML/ from? The ifdguids within do not match those listed in sources such as http://www.buildingsmart-tech.org/ifc/IFC4/Add2TC1/html/link/listing-ifc4_add2.htm (in particular http://www.buildingsmart-tech.org/ifc/IFC4/Add2TC1/html/annex/annex-a/general-usage/IFC4_ADD2.ifc ) or https://github.com/buildingSMART/IfcDoc/blob/express_diagrams/IfcKit/schemas/templates.ifcxml

I modified your code to start testing from the ifc file above. I do note that I still didn't get 100% compatability.
For AirSideSystemType in the ifc published data the globalid is 3UOgG5ejvEzuUrZqX$7VIx but in bsdd the one I found is 3MAn_0qRqHuO00025QrE$V

[klacol]

Hi Jon,

thanks for your feedback. The folder with the original source PSets is now in this repos here:
https://github.com/buildingSMART/bSDD/tree/master/PSets/XML

I took them from here (IFC ADD 2):

http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/link/listing-ifc4_add2.htm
http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/annex/annex-a/general-usage/IFC4_ADD2-psd.psdzip

Did you read this issue and did you transform the GUIDS from the PSets before comparing them?

Let us concentrate on the Pset_TransportElementCommon.YAML:

Official PSet
(including a commit for the german translation, I shoul have made a tag for the intitial commit as a Release)

Latest Draft of the PSet in the XML serialization

Latest Draft of the PSet in the new proposed YAML-PSet Format

Hope, I made no error on transferring the right version of the PSets. We should control this very in detail.

[atomczak]

Closing this thread. My understanding is that now the approach is to use a dedicated GitHub repository for pset management. In case of IFC4.3 that is: https://github.com/buildingSMART/IFC4.3.x-development/tree/master