Additional attribute request for IfcClassificationReference

I’d like to hear other opinions on a request I have with respect to some new attributes to be added to IfcClassificationReference

I’d like to be able to include some revision history when publishing a classification within an object library context. In particular the status of the reference (particularly to nominate if it’s now obsolete), the version the reference was added, and the version it was made obsolete if appropriate.

Do you mind writing some pseudocode demonstrating the current state, and then some code showing what you’d like to achieve? I feel that would be clearer :slight_smile:

Hi Moult,

Refer below for some sample IfcXML for publishing Uniclass2015 https://www.thenbs.com/our-tools/uniclass-2015

As the classification is released approximately every quarter, I’d like to see the IFC datamodel include some more optional attributes for tracking changes and revisions.
IfcClassification you will note has an attribute EditionDate, but I’d like to be able to locally nominate similar for the classification references.

This will be quite helpful in terms of validating IFC models from the perspective of asset operations and maintenance.

Does this make more sense?

Cheers,

Jon

  <IfcProjectLibrary GlobalId="1KJy$VmTH6TeHtXzadneSq" Name="Uniclass2015">
    <HasAssociations>
      <IfcRelAssociatesDocument GlobalId="0W_br$eST53fzO5HxWfXfM">
        <RelatingDocument Identification="Licensing" Name="Creative Commons Attribution-NoDerivatives 4.0 International" Description="The unified classification system for the construction industry was developed by the Construction Project Information Committee with assistance from a government funded research project and first published in 1997.  Uniclass 2015 is a development of this unified classification system by NBS and is licensed for use under the terms of the Creative Commons Attribution-NoDerivatives 4.0 International licence." Location="https://creativecommons.org/licenses/by-nd/4.0/" xsi:type="IfcDocumentInformation" />
      </IfcRelAssociatesDocument>
      <IfcRelAssociatesClassification GlobalId="0llgE2emv1AhGxIxYwg0sp">
        <RelatingClassification Source="NBS" EditionDate="2018-09-05" Name="Uniclass2015" Location="https://toolkit.thenbs.com/articles/classification/#classificationtables" xsi:type="IfcClassification">
          <HasReferences>
            <IfcClassificationReference Identification="Ac" Name="Activities" Description="Ac Activities - 05 September 2018 - v1.7">
              <HasReferences>
                <IfcClassificationReference Identification="Ac_05" Name="Project management activities">
                  <HasReferences>
                    <IfcClassificationReference Identification="Ac_05_00" Name="Strategy stage activities">
                      <HasReferences>
                        <IfcClassificationReference Identification="Ac_05_00_10" Name="Business case development" />
                        <IfcClassificationReference Identification="Ac_05_00_80" Name="Strategic brief preparation" />
                        <IfcClassificationReference Identification="Ac_05_00_82" Name="Strategic brief submission" />
                      </HasReferences>

Surely the IfcClassificationReference should derive its EditionDate from the IfcClassification it relates to? If it is referring to an older edition of the classification, then two IfcClassifications should be created, one with the older edition, and one with the newer edition. So I don’t see why we need to put a new EditionDate in the IfcClassificationReference.

I hope I haven’t misunderstood.

You might be right.

As the classification will frequently change (ie every quarter for Uniclass) then software and projects will have to manage the mapping of changes to make when older project data is encountered. To my mind, being able to track and store obsolete classification references would be handing in a common data store, but this can be done in a bespoke manner if it’s deemed inappropriate to tag within Ifc datamodel. Maybe the obsolete mapping is just to truncate the item code until it is still valid, but I suspect most projects would desire a more refined mapping.

@jonm, is there any reason to use “full classification” for standard classification?
I would use 'lightweight" for all classification with known external source and use IfcClassification.Source + .Edition or .Location to identify where to get tree from.
“Full classification” should be a use-case for custom classification systems.