rationalise the use of IfcPropertySet for all properties / unify the current separation between property sets and quantity sets

[TLiebich]

There are two separate structures for exchanging property sets and quantity sets. But in reality it is often difficult to determine, what is a property and what is a quantity. And both structures are 90% identical.

Merging both into an enhanced definition of IfcPropertySetwould remove potential duplication and redundency and simplify the schema without a loss of functionality.

[pipauwel]

I agree. And I furthermore suggest to put them all directly with the object, with the object, to further limit the possibility to define conflicting attributes with the same name. Something like:

"Class": "IfcWallStandardCase",
"Name": "Wall xyz",
"Description": "Description of Wall",
"GlobalId": "fc844dd2-f71a-4a85-8010-8cd7154504a7",
"Volume": 181698.20138837994,
"Combustible": false,
"ThermalTransmittance": 0.24,
"IsExternal": true,
"ExtendToStructure": false,
"LoadBearing": false,
"Compartmentation": false

[jwouellette]

@pipauwel I think this needs to be considered more carefully. By that I meant that we should more carefully evaluate what is an "attribute" of a class/object - something which is inherent or immutable in its definition (e.g. width, height, area, volume... quantities) - versus a "property" of a class/object - something that may be more fluid and have other dependencies (e.g. combustibility, thermal properties, ... which are dependent on material) [maybe my examples could be better].

However, this might also be complicated by determining type values and instance overrides... a concept which should NOT be lost.

[jwouellette]

Is this directly related to https://github.com/buildingSMART/NextGen-IFC/issues/15?

[pipauwel]

It is somewhat related to #15. The original issue is different though - I diverted. Original issue: QuantitySet and PropertySet should be merged. I agree to that.

[tldddd]

I agree to merging quantity sets and property sets.

I understand the rationale that based on strict dictionary definitions "quantities" are not "properties", However, common use is that all meta data (properties and quantities) go into "property sets".

[berlotti]

Meets the requirements of https://github.com/buildingSMART/NextGen-IFC/wiki/Ten-principles-for-a-future-IFC

Decision: call everything IfcPropertySet. No differentiation on quantity sets. Add additional information to the properties/sets about. This is related to the PDT (CEN) discussion to add attributes to properties as well. Need input from @klacol

[klacol]

First, we have to differentiate carefully, IMHO:

IfcSimplePropertySetTemplate containing many IfcSimplePropertyTemplate Definitions of the properties themselfs, also know das data templates, containing things like data type, measures, units, definition, translations, and so on.

IfcSimplePropertySet containing many IfcSimpleProperty Values of the properties, containing just a simple key/vale pair, but no definition of the properties. In a good design, every IfcSimplePropertySet is related to its IfcSimplePropertySetTemplate.

Therefore I find it somehow dangerous to speak only about the IfcPropertySet. So, we could always try to include them both in such a discussion: the templates and the values.

I think about the templates as an IFC mechanism to dynamically define the late binded definition of properties.

I do not know STEP good, but it would be a dream to be able to reference a dynamically included IfcSimplePropertyTemplate, directly in the object, in the direct-notation as @pipauwel has shown.

"Class": "IfcWallStandardCase",

Static definition of some global properties (from IFC schema), e.g.

Name: IfcLabel
Description: IfcText
GlobalId: UUID

Dynamic definition of late binded properties (frome elsewhere), e.g.

"IfcPropertySetTemplate" : "MyGreatDataTemplate"
   "Volume": "IfcReal",
   "Combustible": "IfcBoolean",
   "ThermalTransmittance": "IfcReal",
   "IsExternal": "IfcBoolean",
   "ExtendToStructure": "IfcBoolean",
   "LoadBearing": "IfcBoolean",
   "Compartmentation": "IfcBoolean",

The object defined by the class and the late binded property templates:

"IfcWallStandardCase.Name" : "Wall xyz",
"IfcWallStandardCase.Description": "Description of Wall",
"IfcWallStandardCase.GlobalId": "fc844dd2-f71a-4a85-8010-8cd7154504a7",
"IfcWallStandardCase.Volume": 181698.20138837994,
"IfcWallStandardCase.Combustible": false,
"IfcWallStandardCase.ThermalTransmittance": 0.24,
"IfcWallStandardCase.IsExternal": true,
"IfcWallStandardCase.ExtendToStructure": false,
"IfcWallStandardCase.LoadBearing": false,
"IfcWallStandardCase.Compartmentation": false

ore more elegant:

"IfcWallStandardCase"
     "Name" : "Wall xyz",
     "Description": "Description of Wall",
     "GlobalId": "fc844dd2-f71a-4a85-8010-8cd7154504a7",
     "MyGreatDataTemplate"
          "Volume": 181698.20138837994,
          "Combustible": false,
          "ThermalTransmittance": 0.24,
          "IsExternal": true,
          "ExtendToStructure": false,
          "LoadBearing": false,
          "Compartmentation": false

(The structure above is illustrative, perhaps we could try to write it in Json-Notation, if is good for the discussion)

The template are mostly referenced as simple (and single) property templates, but there can be many more types, like lists, tables, bounded values, etc.

[klacol]

(The structure above is illustrative, perhaps we could try to write it in Json-Notation, if is good for the discussion)

In Json schema this could be defined like this:

MyGreatDataTemplate.schema.json

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "MyGreatDataTemplate",
    "title": "MyGreatDataTemplate",
    "description": "Schema for data template MyGreatDataTemplate",
    "type": "object",
    "properties": {
        "Volume": {
            "description": "The of the property",
            "type": "number",
            "nullable": true
        },
        "Combustible": {
            "description": "The description of the property",
            "type": "boolean",
            "nullable": true
        },
        "ThermalTransmittance": {
            "description": "The description of the property",
            "type": "number",
            "nullable": true
        },
        "IsExternal": {
            "description": "The description of the property",
            "type": "boolean",
            "nullable": true
        },
        "ExtendToStructure": {
            "description": "The description of the property",
            "type": "boolean",
            "nullable": true
        },
        "LoadBearing": {
            "description": "The description of the property",
            "type": "boolean",
            "nullable": true
        },
        "Compartmentation": {
            "description": "The description of the property",
            "type": "boolean",
            "nullable": true
        }
    },
    "required": [
        "Volume",
        "ThermalTransmittance"
    ]
}

IfcWallStandardCase.schema.json

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "IfcWallStandardCase",
    "title": "IfcWallStandardCase",
    "description": "Schema for objects of the type \"IfcWallStandardCase\"",
    "type": "object",
    "properties": {
        "GlobalId": {
            "description": "The unique id of the wall in the UUID notation according to IETF RFC 4122, e.g 123e4567-e89b-12d3-a456-426655440000",
            "type": "string",
            "maxLength": 36,
            "nullable": true
        },
        "Name": {
            "description": "The name of the wall",
            "type": "string",
            "maxLength": 255,
            "nullable": true
        },
        "Description": {
            "description": "The Description of the wall",
            "type": "string",
            "maxLength": 3000,
            "nullable": true
        },
        "LateBindedDataTemplate": {
          "description": "Definition of a data template that can be lately binded to the schema. The late binded properties are not part of the core specification",
          "$ref": "MyGreatDataTemplate.schema.json"
        }
    },
    "required": [
        "GlobalId",
        "Name"
    ]
}

With this, it is possible in Json to create a valid instance file of IfcWallStandardCase that does allows the access to the core properties and the late binded properties.

{
    "GlobalId": "fc844dd2-f71a-4a85-8010-8cd7154504a7",
    "Name": "Wall xyz",
    "Description": "Description of Wall",
    "LateBindedDataTemplate": {
        "Volume": 181698.20138837994,
        "Combustible": false,
        "ThermalTransmittance": 0.24,
        "IsExternal": true,
        "ExtendToStructure": false,
        "LoadBearing": false,
        "Compartmentation": false
    }
}

The sample doe not reflect the complete IFC namespace, since Json-Schema does not support all the structures, that IFC needs, but it shows, how other systems try to implement late binding.

Perhaps we can find some ideas in the way, they combine schemas with the keywords "allOf", "anyOf","OneOf" and "not".

The three sample files can be found here.

For a real dynamic late binding, the reference of the data template would have to support some kind of wildcard system, perhaps like this

"$ref": "MyExtendedDataTemplate*.schema.json"

[berlotti]

@klacol this is also strongly related to the EIR: https://github.com/buildingSMART/EIR/blob/master/examples/project%20and%20site%20properties/project_and_site_EIR.txt

[klacol]

@klacol this is also strongly related to the EIR:

Yes, many thinks are related to EIR and Level of information need, e.g.

• Classes in Classification systems
• TypeObjects
• DataTemplates
• Product data

It is all one big roundtrip, over severall distributes model(database)s.