buildingSMART Forums

Lack of standardisation of IfcClassification

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:

https://wiki.osarch.org/index.php?title=IFC_classifications

I invite others to critique and let me know their conventions (as well as add other classification systems).

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

Sylvain

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.

1 Like
  • 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 :sweat_smile:). ‘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 :slight_smile:

Any link to that initiative?

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.

As far as I know CoClass team/consortium was following such approach some months ago

Also, IfcXtreme (which is better I don’t talk about it, yet)

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

Regarding bSI standardization, I always thought that the Classifications would end up in the bSDD…

1 Like

@michelangelo bsDD sounds like a good place!

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…

1 Like

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.

https://www.graphisoft.com/downloads/archicad/BIM_Data.html

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.

2 Likes

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…

1 Like

@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 :slight_smile: (I believe, not 100% sure)

Thank you, yes, also as far as I know more classifications did it, for instance, another one is Uniclass

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