bSDD -- GUIDs at the field (property) level

Developers bSDD
1

One of the presentations yesterday at the bSI summit plenary implied that software developers should supoort (in addition to the object-level or concept-level GUID), GUIDs at the individual field or property level.

This concerns me, as it seems redundant. Currently, a property is uniquely identified by the pSetName.propertyName tag. I understand that this field identifier needs to have a GUID within the bSDD ontological structure (to allow the bSDD magic to work), but I can’t find the value in exposing the field-level GUID to users (or outside consumers of the bSDD, such as software developers,)

It seems counter-productive, even, because it introduces an additional need to synchronize the GUID with the existing pSet.field name.

Can someone with more expertise in this topic than I have, please clarify this, either giving a use-case that justifies this GUID convention, or confirming that these GUIDs will not be required?

2

If I understand your question properly, I would have to say that using any “name” rather than a GUID to refer to a property is always dangerous.

For one thing, a property name is language dependent. Even between English speaking languages there are different terms for the same thing (fire resistance is a common term used for a wide variety of properties that are related to fire but are in fact different). “Fire resistance tested to EN1234” is not the same thing as “fire resistance to UL5678”, even though both are measured in hours.

If the Property name is a published IFC property this might work OK, but we need many properties which are not IFC properties. We could not refer to those properties using a name because they would not be part of a pset.

Hope this helps.

2 Likes
3

Trying to add to this as well. So, if I understand correctly, you would like to just use the GUID for pSetName, and not for the propertyName as well, since propertyName is unique within the pSetName namespace.

However, that assumes that there is always a pSetName defining a group of properties that you, or the user, would need. This is not the case. As @Specwhiz shows, “fire resistance” has many variants, depending on context, country, etc.

Another point is that a pSetName may work fine for one setting in one phase of the project, it most certainly will not work in another setting in another phase. For example, the need for properties in a maintenance and operations phase, is totally different, usually, from what is needed in the procurement / logistics phase of the project.

~ Håvard.

1 Like
4

I was referring earlier, (although i may not have made this clear) to properties in the standard IFC schema. Håvard, to write the data, I need pSet name as well as property name. This is of course unique with regards to the standard schema (NOT custom pSets.)

It would seem that GUIDs then are a “band-aid” solution for the fact that IFC was not developed as an internationalizable standard. But aren’t all “standard” IFC properties already entered in the bSDD as references along with GUIDs?

I’m not sure I find the ‘fire rating’ example convincing. it would have to be a part of my BIM project execution planning which fire standards I use.

5

In theory, if you are using standard IFC Psets, having a GUID on the PSet itself, and not the individual properties, should be enough in terms of identifying properties, since the pSetName.propertyName tag is unique.

From my impression, the standard IFC Psets fall short in terms of carrying the data that a lot of clients requests, so I suspect that you will soon need to support the individual GUIDs on properties, going forward.

But I may be wrong, and I may be not understand your use case correctly.

~ Håvard.

1 Like
6

This is certainly true. We’ve been discussing this (mostly internally with @klaus.aengenvoort and some other people) since a few years; - as far as I remember we talked about this with @TLiebich in February 2014, also regarding this related topic: How is a IfcPropertySet related to its IfcPropertySetTemplate? - #2 by stegh

From my point of view: GUIDs would certainly help.

@jonm also supports this… :wink: How is a IfcPropertySet related to its IfcPropertySetTemplate? - #4 by stegh

7

Having seen the ETIM presentation in Tokyo, I understand better why GUIDs are needed at the property level. It’s clear that the standard IFC pSets are a small fraction of what is desired by industry.

8

The biggest limitation I see with using GUIDs for everything is that they are (by concept) different for you and me. When I define a property “MyPset.MyProp” it gets a guid in whichever software or DB I use. When you define the same property with the same (unique) name, it gets a different guid. What will happen when you want to synchronise?

This requires a centrally organised repository where the guids are generated and can be requested. This is totally different from the way we now generate guids. When you export models, your software produces these guids, but doesn’t start asking a central library (bSDD etc…) for that guid. And how would you even find the guid? By searching on … the property name and property value in text form.

E.g. ARCHICAD has guids internally, but doesn’t export them out. Revit uses them for Shared Parameters (but the users never see them). But I have the feeling that they are not even necessary. With guids you need to map. With translations you need to map as well. What’s the difference? And you could say that you may change the name of a property and retain the guid. Does that make sense? Is it the same property if you change its name?

(I have the feeling that we try to solve every problem by using guids)

1 Like
9

This is an interesting discussion here and yes, we can not solve all problems with Guid’s.

For me it is clear, that a property needs a technical key, that identfies the property itself. Without this key, we will not have a reliable and automated usage of properties.

The key can be human readable and/or machine readable, but it should never change its value over the life cycle of a property.

In a discussion over at GitHub I worked with the two ways.

Example:

Name of PSet: Pset_TransportElementCommon
Name of property: CapacityPeople
IfdGuid: 003Z60qX8HuO00025QrE$V

See this link to view the complete PSet.

The unique key in human readable notation would be this: Pset_TransportElementCommon.CapacityPeople. This key is also machine readable. This key must be the combined key of the PSet and the property. The name CapacityPeople is only unique within the PSet Pset_TransportElementCommon.

The GUID is only machine readable and should never be exposed to users. The GUID is unique also without the name of the PSet.

In my opinion, even the notation Pset_TransportElementCommon.CapacityPeople should not be exposed to end users. They should work with the translated term in their language, or if not exists in englisch language.

See all available languages here.

So, the end user should see this: capacity people
(no Pascal case, with space in between)

And the end user shoul see the definition: Capacity of the transportation element measured in numbers of person. This ensures, that the end user understand the semantic meaning of capacity people and put in the correct value, according the the definition.

The desicion if to use a human readable notation and/or a machine readable notation is related to this question:

“Will the name of the property ever change?”

If you say “no, never, really never ever”, then you are good to go with the human readable notation. If, for some reason, you cannot answer this question, or if you have to say “Yes, that might be the case at some time”, then you should go the way with the machine readable notation. IMHO buildingSMART goes a dual way as of today and that is a point of confusion, but it is not bad, since it it easy to keep the keys in sync as long as the answer stays “No”.

I am looking forward to your feedback.

1 Like