How to distinguish between psets and qtos? about bsdd HOT 7 CLOSED

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

from bsdd.

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.

from bsdd.

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.

from bsdd.

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.

from bsdd.

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?

from bsdd.

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.

from bsdd.

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

from bsdd.