Yes. The original purpose of this thread was actually more about standardising the metadata of commonly known classification systems, but we’ve since been distracted with mappings 
This is called Knowledge base, this is why some work on ontology like IfcOWL (OWL/RDF, JSON-LD).
So, classifications can have the same path which have and some worked/work on it
Each classification has developed for a specific purpose, so in Exchange Requirements (ERs), companies can specify which classifications are suitable for “which purposes”
If the interest is high could that be a bSI Activity Proposal to be addressed in one of the bSI Rooms maybe?
Here in the Netherlands IFC is already “mandatory”. They have made a list of all standards that shall be used in a socalled “apply or explain” list. But this is one governement telling the other department one how data of construction shall be done. When it comes to real world projects with private parties involved the game changes, a lot. One disadvantages a exclamation like this has is that it can only be used 1 time effectively. So tooling should be in place and it can’t have bugs or child diseases. I think in NL this demand was forced a bit too early but nevertheless ifc use grown tremendous. But that is not because this at all. And then there is a cultural thing besides it too… ever talled a dutch what he or she should or should not do as an authority??? Well then you probably know how this will go. 
dutch are anti-authorrity minded.
A heads up that the table has been updated for all of the systems that Graphisoft supports:
https://wiki.osarch.org/index.php?title=IFC_classifications
In addition, all classification systems, instead of being provided in XML format (like Graphisoft’s approach) is now provided in IFC format, to mitigate any inconsistent values inside the IfcClassification and IfcClassificationReference entities. They have been published here:
It is worth noting that the BlenderBIM Add-on can now read these IFC project libraries and use it to display a classification hierarchy for users to filter from.
1 Like
An update that now FreeCAD can also consume these IFC resources.
Other vendors are also welcome to consume them and implement similar features.
@Moult, thanks, your GitHub repro is very valuable!
As I understand IFC file with a design model should not include the classification tree, it should use “lightweight” classification and only reference to classification systems.
XML and IFC project libraries with “full” classifications are external and shared resources, this information should not be embedded in every IFC file.
is it correct?
@igor.sokolov I agree that an IFC file with a design model should not contain the entire classification tree. The full classification tree is to be distributed purely as an IFC project library, which is the purpose of the resource I created. You are correct.
However, I will like to add in detail that although the design model should not contain the entire classification tree, it is my understanding that to be semantically correct, it should contain the full inheritance tree of any leaf nodes which are relevant to the model.
E.g. If a classification Foo contains Foo_X, Foo_X_Y, Foo_A, Foo_A_B, and Foo_A_B_C with the _ character being the hierarchy separator, and a model is assigned a classification Foo_A_B, it should include an IfcClassification of Foo, a IfcClassificationReference of Foo_A_B, and it should addtionally contain Foo_A through the HasReferences attribute, even though Foo_A is never directly assigned to an object. It does not need to include Foo_A_B_C, Foo_X and Foo_X_Y since they are never assigned to anything.
The reason for excluding the non-assigned classification references are exactly as you mention - we only need to reference a classification system, not describe the full tree.
The reason for including the indirectly-assigned classification references is to maintain semantic correctness - that is, if I then search my model for Foo_A, I should also expect Foo_A_B to come up in a search result.
It also means that upon consumption of a model, I can immediately see the subset of the full classification tree to help me understand what a model does and doesn’t contain - in contrast, if I only see the leaf nodes (e.g. Foo_A_B but not Foo_A), then it is very hard to understand the model scope.
Hope it makes sense.
1 Like
I thought that using a Classification Reference gives you the possibility to reference a single “leaf” of the whole classification system? As long as the classification item can identify the classification system, you don’t need to embed the whole classification system nor the parent classification items into your project.
Following that reasoning, I don’t understand the requirement for also having to include every parent item up till the root.
EXAMPLE The IfcClassificationReference can be used as a form of ‘lightweight’ classification through the ’ Identification ’ attribute inherited from the abstract IfcExternalReference class. In this case, the ’ Identification ’ could take (for instance) the Uniclass notation “L6814” which, if the classification was well understood by all parties and was known to be taken from a particular classification source, would be sufficient. The Name attribute could be the title “Tanking”. This would remove the need for the overhead of the more complete classification structure of the model.
1 Like
It is not illegal behaviour to only provide a leaf with nothing else as far as the spec goes, and certainly if your usecase is around conventions agreed by well known parties, go ahead and be as light as you want 
I have a slightly different usecase where there are requirements on the longevity, reference of unfamiliar parties, and standardised data cataloguing of IFC - which is why I have taken a compromise approach to include leafs, and all branches that lead to that leaf (but I still exclude everything else). I have chosen this compromise approach due to the following two disadvantages of a purely lightweight classification reference:
- If only the leaf is referenced without any
HasReferenceofIfcClassification, this means a fresh viewer has no idea which classification it is part of. Is it part of Uniclass 2? Uniclass 2015? Who knows. - If the leaf is referenced with a
HasReferencetoIfcClassification, but with no parent classes in-between, then if the user wishes to understand a summary of classifications relevant to the project, it may be difficult, due to the flattened tree. Software searches to find (grand*)children of a parent may also fail since the tree data isn’t there. Reference tokens mitigate this issue, but do not completely solve it as some classification systems don’t have a reference token.
This is merely a convention I have established. You do not need to follow it if it doesn’t apply in your usecase, but if you do see value in it, I have provided the resources online to help achieve it
Also, regardless of workflow, I’m sure it is useful for data authoring that we now have a repository of classification systems in IFC format available for everyone
Colleagues, please clarify that if we are considering the MVD “Reference view”, it is probably possible to show brief information on the classification, since we can assume that the work is carried out within the same project in the same time period. If we are considering the use case of using IFC for long-term storage of the model, then it is necessary to somehow specify the classification version and probably specify all the classification information so that any application can not only read the model, but also show the classification to the model Or do I not understand the approach of specifying the classification of the model correctly?
1 Like
Dear All,
there is already a project, which is currently going on in particular to map not only different Classification Systems but also IFC versions as well as languages…and push new ones into bSDD.
The project Called “BIMeta” in other words BIM and Meta Data. The central role plays IFC Shema of course, as a single source of Truth! The Team Members has already established contact with @berlotti.
I will try to invite Tim Hoffeller and @klaus.aengenvoort (is already here) into the bS Forum. So that you may ask them questions directly.
All the best,
@mirbek.bekboliev
Hi Mirbek,
Interesting, where can we find more info on this project?
Thanks
Sylvain
Hi @SylvainMARIE,
I would suggest you to contact @klaus.aengenvoort. He is one of the Team Experts in particular for this topic.
Greetings,
Mirbek
Can buildingSMART investigate implementing a policy to have these project discussions “in the open” on public channnels like this discourse forum, non password protected chatrooms, and Github issues? This can help prevent future double up of work and lack of user / community awareness.
1 Like
@Moult FYI, a project that I have mentioned, “BIMeta”, is not bS Project. I’m not sure if your proposal would work due to the GDPR Issues and protection against SPAM. As far as I know bS Forum is open for everyone but with one small restriction that users should be registered.
1 Like
In my opinion, it is a good policy to preserve user registration.
SPAM is every day smarter and smarter.
2 weeks ago in a meetup online event in which I participated… some bots, users, whatever they were, sharing porn profile images, unmuting with background music, etc, etc,…
To clarify, I am not suggesting removing user registration. I’m suggesting that many of these projects are discussed behind closed doors. Or, rather, participants are by “invite-only”. In contrast, forums, Github issues, and public chatrooms (which does not exclude registration) have been used very successfully in the IT industry, and has helped fostered collaboration on very large complex projects.
3 Likes
I am currently working with CFIHOS and RDS-PP. Both are industrial classification systems, which we use for wind power generation. Would there be someone with experience of these classification systems and mapping to IFC?