buildingSMART / bSDD

The buildingSMART Data Dictionary repository, where we publish the documentation, examples and more. We don't publish here the data, the source code of the bSDD service or the front end of the website.
https://www.buildingsmart.org/users/services/buildingsmart-data-dictionary/
MIT License
129 stars 36 forks source link

How to distinguish between psets and qtos? #77

Closed Moult closed 2 months ago

Moult commented 9 months ago

Here is some sample response from the bSDD. Notice how some properties associated with this classification are psets and some are qtos. I can't find any way to clearly distinguish between the two (apart from heuristic checks like starting with "Qto_"):

{
    "referenceCode": "L-ULM",
    "synonyms": ["Wall"],
    "relatedIfcEntityNames": ["IfcWall", "IfcPlate", "IfcPlateStandarsCase"],
    "parentClassificationReference": {
        "namespaceUri": "https://identifier.buildingsmart.org/uri/molio/cciconstruction/1.0/class/L-UL_",
        "name": "Structural supporting object",
        "code": "L-UL_",
    },
    "classificationProperties": [
        {
            "name": "FireRating",
            "description": "Fire rating for this object. It is given according to the national fire safety classification.",
            "dataType": "String",
            "propertyCode": "FireRating",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/FireRating",
            "propertySet": "Pset_WallCommon",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "ThermalTransmittance",
            "description": "Thermal transmittance coefficient (U-Value) of an element, within the direction of the thermal flow (including all materials).",
            "dataType": "Real",
            "propertyCode": "ThermalTransmittance",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/ThermalTransmittance",
            "propertySet": "Pset_PlateCommon",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "StrengthClass",
            "description": "Classification of the concrete strength in accordance with the concrete design code which is applied in the project.",
            "dataType": "String",
            "possibleValues": [
                {"code": "100MPa", "value": "100 MPa"},
                {"code": "8MPa", "value": "8 MPa"},
                {"code": "12MPa", "value": "12 MPa"},
                {"code": "16MPa", "value": "16 MPa"},
                {"code": "20MPa", "value": "20 MPa"},
                {"code": "25MPa", "value": "25 MPa"},
                {"code": "30MPa", "value": "30 MPa"},
                {"code": "35MPa", "value": "35 MPa"},
                {"code": "40MPa", "value": "40 MPa"},
                {"code": "45MPa", "value": "45 MPa"},
                {"code": "50MPa", "value": "50 MPa"},
                {"code": "55MPa", "value": "55 MPa"},
                {"code": "60MPa", "value": "60 MPa"},
                {"code": "70MPa", "value": "70 MPa"},
                {"code": "80MPa", "value": "80 MPa"},
                {"code": "90MPa", "value": "90 MPa"},
            ],
            "propertyCode": "StrengthClass",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/StrengthClass",
            "propertySet": "Pset_ConcreteElementGeneral",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "Height",
            "description": "Characteristic height",
            "dataType": "Real",
            "propertyCode": "Height",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/Height",
            "propertySet": "Qto_WallBaseQuantities",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "Length",
            "description": "The length of the object.",
            "dataType": "Real",
            "propertyCode": "Length",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/Length",
            "propertySet": "Qto_WallBaseQuantities",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "ConstructionMethod",
            "description": "The type of construction action to the object, e.g. new construction, renovation, refurbishment, etc.",
            "dataType": "String",
            "possibleValues": [
                {"code": "Pre-fabricated", "value": "Pre-fabricated"},
                {"code": "In-situ", "value": "In-situ"},
            ],
            "propertyCode": "ConstructionMethod",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/ConstructionMethod",
            "propertySet": "Pset_ConcreteElementGeneral",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
        {
            "name": "IsExternal",
            "description": "Indication whether the element is designed for use in the exterior (TRUE) or not (FALSE). If (TRUE) it is an external element and faces the outside of the building.",
            "dataType": "Boolean",
            "propertyCode": "IsExternal",
            "propertyDomainName": "IFC",
            "propertyNamespaceUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/IsExternal",
            "propertySet": "Pset_WallCommon",
            "propertyStatus": "Active",
            "propertyValueKind": "Single",
        },
    ],
    "classificationRelations": [
        {
            "relationType": "HasReference",
            "relatedClassificationUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcWall",
        },
        {
            "relationType": "HasReference",
            "relatedClassificationUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcPlate",
        },
        {
            "relationType": "HasReference",
            "relatedClassificationUri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcPlateStandarsCase",
        },
    ],
    "domainNamespaceUri": "https://identifier.buildingsmart.org/uri/molio/cciconstruction/1.0",
    "activationDateUtc": "2020-01-01T10:23:00Z",
    "code": "L-ULM",
    "creatorLanguageCode": "da-DK",
    "countriesOfUse": [],
    "countryOfOrigin": "DK",
    "definition": "structural supporting object in a plane or curved surface form withstanding compression forces",
    "name": "Wall plate",
    "namespaceUri": "https://identifier.buildingsmart.org/uri/molio/cciconstruction/1.0/class/L-ULM",
    "replacedObjectCodes": [],
    "replacingObjectCodes": [],
    "revisionNumber": 1,
    "status": "Active",
    "subdivisionsOfUse": [],
    "versionDateUtc": "2020-01-01T10:23:00Z",
}
atomczak commented 9 months ago

Hi @Moult.

First of all, I see you are using the old API before the update of the data model. It's still supported, but you might want to check out the new version: https://app.swaggerhub.com/apis-docs/buildingSMART/Dictionaries/v1 (we post about changes here: https://forums.buildingsmart.org/t/bsdd-tech-updates/4889/17).

bSDD is a universal platform for many data dictionaries, and IFC is just one of them. The attribute 'Property Set' was added to support mapping properties from other data dictionaries / classification systems to IFC data model. Since Pset and Qto are reserved IFC prefixes, and no other data dictionary can use them, there is no attribute in bSDD to differentiate them. Yes, the best would be to do the heuristic check. Can you explain why do you need it?

By the way, there is a new version of the IFC data dictionary coming. It's already available on the Test server in version 4.3.1: https://search-test.bsdd.buildingsmart.org/uri/buildingsmart/ifc/4.3.1. The main change is that we added missing classes and properties (also attributes and inherited properties), as well as normalised names and descriptions. After tests, the 4.3.1 will become the current version 4.3 (we will override the IFC data dictionary).

Moult commented 9 months ago

Can you explain why do you need it?

One of the features of bSDD is to use the bSDD to assign classifications, and in turn, auto assign properties and quantities associated with those classifications. However, it's not currently possible to know whether that is a property or a quantity.

The heuristic check of Pset or Qto prefix works for IFC properties and quantities, but what about non-IFC properties and quantities? E.g. a local government registering their own properties and quantities in the bSDD? How will we know then?

If you're up for a screenshare I can demonstrate this problem in Blender.

atomczak commented 8 months ago

Quantities are also properties, and it's very IFCsh to distinguish the two... Hopefully, this will be simplified in the next-generation IFC. Is there some benefit of having them separately that I don't see? Of course, we can meet if easier to demonstrate.

Anyway, the bSDD follows ISO12006/23386 and only distinguishes classes and properties.

Moult commented 8 months ago

The difference between the two in IFC are:

  1. Quantities can have a method of measurement attribute, which is criticial to know if used properly.
  2. Quantities can include a description to describe exactly what is being quantified.
  3. Quantities can include a formula to show how it was calculated!
  4. Quantities can be linked parametrically to resource utilisation, cost calculations, and task durations, whereas properties cannot.
  5. Quantities are simpler to implement than properties. This means that implementers who wish to simply build costing / take-off type software / utilities have less to do than if they needed to support properties.

This doesn't mean that properties and quantities can be merged in the future, just that right now properties and quantities are different / can do different things in IFC.

atomczak commented 8 months ago

Yes, I know about the differences between props and quantities in IFC (anyway, thanks for explaining, as I learnt about some just now!). I'm interested if there is a benefit of distinguishing them in data dictionaries? Popular software like Revit has only properties anyway, and those can take formulas and be derived. The fact that IfcPropertySingleValue doesn't have a description is just one of many IFC shortcomings.

Do we want/allow people to create their own custom quantities in IFC? I always thought that those were only limited to the official IFC Qtos. @berlotti @aothms?

Moult commented 8 months ago

Most software already create custom quantities. In IFC2X3 you have no choice but to create custom quantities, and in IFC4 I have seen custom quantities from Revit, ArchiCAD, and Tekla. Note that quantities (and things specific to quantities, like method of measurement) are also required in standards like COBie in the US and UK. I also daily use custom quantities for things that IFC have not yet defined like formwork quantification.

atomczak commented 2 months ago

We don't (plan to) have a distinction between properties/quantities/attributes in bSDD.