buildingSMART does not (and rightly so) dictate exactly what values are allowed in the IfcClassification entity. However, this becomes a problem when BIM authors export IFCs which mean the same thing (most of us use a handful of very well known classification systems) but have different values. Similar to the work done in standardising on EPSG codes for georeferencing, I propose that a reference table be published for well known classification systems.
The OSArch community has got one here, and these are shipped with the BlenderBIM Add-on:
2-3 years ago I shared that almost all classifications today exists are not complete enough
What you call classification itâs related to âmeaningâ: and âlanguageâ and its parts as âontology, semantics, and syntaxâ and in reality language has limitations
So, you can list some known or well-known classification standards, but at the end âyou have to let all talk in a language they want and they can understandâ
This is why sometimes I purposefully use some things interchangeably, like IFC4.2 or IFC4x2, âŚ
However, as mentioned those classifications are not complete
Hi @Moult,
Stakeholders often define their own classifications (latest example in mind: a mix of Uniformat and specific thesaurus to create an ad-hoc marine port classification), their number is meant to growth more than GIS projections. Also, I am not sure forcing to use a closed list would be compatible with the long process of standardization.
How about using the Source field as the primary key, as it is used to store a URI? (except in your table?)
Hi @SylvainMARIE - I am not proposing restricting users to a preset list of classifications. There is no forcing to use a closed list.
Instead, I am proposing that should a user wish to use an âout-of-the-boxâ classification system, such as purely Omniclass, Uniclass, Uniformat, etc, that they always fill out the values in a standardised way, to make data cleaner.
If a stakeholder wants their own classification system, they are free to do so.
Similar to GIS projections, there is a registry for commonly used CRSes. There should be a registry for commonly used classifications.
Also, source is not used to store a URI. See here for the documentation, which states that the Location attribute stores the URI.
Source/Location field
Thank you for the correction. Silly me, I was looking at some old fashioned IFC file and associated documentation (never trust your search engine first answer ). âLocationâ it is. Still, could this URL be considered as a primary key instead of the name?
Open registry instead of a closed list
Great idea. This could be the default public pointer to pick common classifications from. I guess then the question is about data governance (disambiguation, authority, updates, etc.): bSI could maintain that page, and it could be updated during the bi-annual technical summits?
Something along the line of https://technical.buildingsmart.org/resources/information-delivery-manual/idm-database/?
Some have started to develop collaborative classification systems, which âit seems thatâ use URL as identifier and is API-based, also have search/query ability, and if you donât find your desired class you have the ability to add it to the database as a user
@SylvainMARIE - I think URI would be a good choice for a primary key, similar to XML namespaces.
The registry ideally is maintained by someone, yes, which could be buildingSMART, or another. In addition to maintaining updates and disambiguation, they could probably also maintain mappings. E.g. which Uniclass fields are relevant to which IFC classes, and vice versa. That would make software implementations also much more user friendly.
But until an authority steps in to maintain it, the OSArch Wiki is more than happy to provide an unofficial standard, perhaps first adopted by the community
Providing âMappingsâ is interesting indeed. Both ways! (i.e. From IfcClasses to potential helpful classification and predefined ClassificationReferences).
OSArch does have an edge in reaction time, for now. [personal experience: once upon a time I was the maintainer of the BIMGuides wiki, but time allocation comes and goes]. I would be more confortable if I knew such great initiative could safely land on some bSI-managed host.
@SylvainMARIE - FYI, @jonm has started work on some mappings, and I think I read somewhere that @EmmaH from Bond Bryan have also got some mappings. However, neither are released to the public.
In usBIM.viewer+ we have done a lot of work in collaboration with INECO regarding the classifications as they use them extensively.
The application provides some preconfigured ones (see attached screenshot) and has the possibility to create custom ones (from XML or Excel) and to edit the IFC model to add/update/remove classifications to the entities. It then has a Classification Analysis tool to display the classification tree and do checking on the entities (How many have such classification? How many have not? How many have none? Etc.)
Does that screenshot show mappings, or just preconfigured classifications? Iâm more interested in mappings - preconfigured classifications are a standard feature in the BlenderBIM Add-on, FreeCAD, ArchiCAD, RevitâŚ
Not open per se, but Graphisoft published a good list of classifications in a custom XML format, as used inside ARCHICAD. Would be nice that something like this could become an open standard format.
I have created some classification tables from Excel into the format Graphisoft uses (BB/SfB and CCTB) with some Excel formula magic.
Beware: this is NOT mapping and there are no GUIDs (yet once inside the software, each classification term receives a GUID). Mapping is always limited: never 1 to 1, no round tripping and donât expect transitive mapping from A to B to C versus A to C directly.
Molio, the developer of Cuneco Classification System (Denmark) has made some mappings between the CCS classes and IFC entities https://ccs.molio.dk/Navigate/CodeCracker?sc_lang=en-gb
Actually, CoClass and CCS are quite similar, based on the same group standards ISO81346.
Concerning lacking of IfcClassification, I am not sure about the lackings of IFC schema, itâs more lacking of IFC implementation into the BIM Authoring tools. In my opinion, currently, majority of BIM Authoring tools moreless focused only to IFC geometry and main entities.
The use of IFC is an extension of 3d CAD as fileformat. BUT it is highly needed because the AEC software industry had a compatibility problem for a long time. And still has. Having to work with a variety of software to get 1 building project done, which will not go away. Thinking about IFC, just sayingâŚ
@Darius - this post is not criticising the IFC schema. We are talking about standardising implementations.
Thanks for the CCS resource, it is very valuable. Would you like to add it to the OSArch Wiki?
@stefkeB thanks for bringing up the Graphisoft XML files. They are very valuable, and that is what the FreeCAD implementation is based on (I believe, not 100% sure)
Classifications are preconfigured but in XML, so it is possible to modify the existing ones, create new ones, and the ones from Graphisoft works aswellâŚ
âŚthere is also some fields in the XML (not used yet) that can limit the binding of classification nodes to one or more IFC classes, but usually the users of such functionality are expert enough to not mistakenly assign improper classifications.
Im my understanding what you are asking for is that everyone should refer to a (remote) single source of truth regarding classifications and mappings (i.e. which classification nodes can be assigned to which IFC class)?
). âLocationâ it is. Still, could this URL be considered as a primary key instead of the name?
