using BSDD for numeric props

[VladimirAlexiev]

Need intermediate quantityKinds like "height", "width"

aec3po:modular_room_height is declared to be directly under qudt:Length. However, we need an intermediate quantityKind (or property) "height" since IFC has such a property.

Same pertains to eg aec3po:width_of_angled_corridor, which should come under "width" (together with sibling props like door_clear_width, etc).

aec3po/src/quantity_kinds.ttl

Lines 49 to 60 in 5fb6f7e

	aec3po:modular_room_height a aec3po:QuantityKind ;
	rdfs:label "modular room height"@en ;
	rdfs:comment "vertical distance within one storey between the modular plane of the upper surface of flooring and the modular plane of the finished ceiling."@en ;
	qudt:applicableUnit unit:CentiM ;
	qudt:applicableUnit unit:IN ;
	qudt:applicableUnit unit:M ;
	qudt:applicableUnit unit:MilliIN ;
	qudt:applicableUnit unit:MilliM ;
	qudt:hasDimensionVector qkdv:A0E0L1I0M0H0T0D0 ;
	qudt:normativeReference "https://www.iso.org/obp/ui/#iso:std:iso:6707:-1:ed-6:v1:en:term:3.7.2.47"^^xsd:anyURI ;
	rdfs:isDefinedBy aec3po:quantity_kinds ;
	skos:broader quantitykind:Length .

@beachtom , @EdliraK do you agree?

[beachtom]

I do not think we should define any properties of this level of expressiveness - we could use the expression syntax from T2.3 to achieve this without enumerating a wide list of properties

[VladimirAlexiev]

• @maximelefrancois86 has added references to ISO 6707-1:2020 Buildings and civil engineering works — Vocabulary — Part 1: General terms, eg see https://www.iso.org/obp/ui/#iso:std:iso:6707:-1:ed-6:v1:en:term:3.7.2.47.
• @beachtom if you don't want to define such specific property, how would you express it in the syntax you mentioned?

How are such specifics expressed in IFC?

• modular_room_height quite matches https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/property/FinishCeilingHeight.htm (part of https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/Qto_SpaceBaseQuantities.htm), but FinishCeilingHeight talks about suspended ceilings, whereas modular_room_height should also apply to fixed ceilings
  • So @maximelefrancois86 it sounds almost like we should state
    ifc:FinishCeilingHeight skos:broader aec3po:ModularRoomHeight
• @beachtom How would you express "ClearDoorWidth"? https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/Qto_DoorBaseQuantities.htm doesn't have anything appropriate

[beachtom]

We would just define it as ClearDoorWidth in the expression. We would then create such a property in the BSDD or whatever we end up using and map to the IFC. If it doesn't exist in the IFC we can define our own custom propertyset.

[VladimirAlexiev]

@beachtom Ok, so we'll have to define ClearWidth! We have to say:

• label, comment
• ClearWidth broader Width
• dimension vector is L1
• (we don't need to enumerate applicable units if same as the units of Width, see do we need to enumerate all applicableUnit? #29 (comment))
• qudt:normativeReference if it has one

I know how to represent this in BSDD as well (Property definition).
We also have to attach it to the appropriate class Door (ClassificationProperty definition).

Tom, how do we "map to the IFC"?

[beachtom]

So when I last used BSDD about two years ago, we could define the concept in the IFC context (to whatever IFC version) and then link them. They have made changes since. I need to clarify what has changed

Do we need to define this in the ontology, though? Or in this ontology?

I don't think we should create a data property for every thing we may need in the regulations.

Perhaps it is enough to have a BSDD Concept class - and then ClearWidth is an individual? Perhaps even this is not needed.

[VladimirAlexiev]

https://bsdd.ontotext.com/ has a lot of info about BSDD. In particular PlantUML Full Diagram: png or svg

• Classification (to be renamed Concept) has relatedIfcEntityName, eg IfcDoor
• Classification.parent can be used to point to a parent, but only in the same domain
• ClassificationRelation allows to point to a parent in a different domain, including IFC (eg https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/class/IfcDoor)
• PropertyRelation can relate a prop to another (eg an IFC property as captured in BSDD, eg https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/Width), and relationType="IsChildOf" can put this prop under the other.
• (Property and ClassificationProperty have replacedObjectCode, replacingObjectCode. Ontology quick comments buildingSMART/bSDD#31 says they are ISO 12006-3 properties. It is about "being replaced by" and "replacing". If "A" replaces "B" then for "A" ReplacingObjectCode will be "B" and for "B" ReplacedObjectCode will be "A")

[maximelefrancois86]

In its current state, the src/vocabularies is probably unmaintainable.

However it has the benefit to illustrate how things are expected to be defined, and provide examples.

[VladimirAlexiev]

You can see the semantic representation of prop/Width at ONTO's "Semantic BSDD" ( admin / 2rNS*i@mNR@YfS ):

@prefix bsdd: <http://bsdd.buildingsmart.org/def#>.

<https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/Width> a bsdd:Property;
  bsdd:activationDateUtc "2022-12-31T00:00:00"^^xsd:dateTime;
  bsdd:code "Width";
  bsdd:dataType "Real";
  bsdd:description "The width of the object. Only given, if the object has constant thickness (prismatic).";
  bsdd:isDynamic false;
  bsdd:name "Width";
  bsdd:propertyValueKind "SINGLE";
  bsdd:status "Active";
  bsdd:versionDateUtc "2022-12-31T00:00:00"^^xsd:dateTime .

Then you can find usages of Width with a query like this (limiting to IFC classes, you see that we need to hack URLs even for this simple task!)

select * where { 
	?s ?p <https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/Width>
    filter(strstarts(str(?s),"https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3"))
} 

These ?s are bsdd:ClassificationProperty, eg one is class/VehicleROLLINGSTOCK/Width. It relates the prop to a class, and can change prop characteristics (eg here it sets propertySet):

<https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/class/IfcVehicleROLLINGSTOCK/Width>
  a bsdd:ClassificationProperty;
  bsdd:activationDateUtc "2022-12-31T00:00:00"^^xsd:dateTime;
  bsdd:code "Width";
  bsdd:dataType "Real";
  bsdd:description "The width of the object. Only given, if the object has constant thickness (prismatic).";
  bsdd:isDynamic false;
  bsdd:name "Width";
  bsdd:property <https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/Width>;
  bsdd:propertySet "Qto_VehicleBaseQuantities";
  bsdd:propertyValueKind "SINGLE";
  bsdd:status "Active";
  bsdd:versionDateUtc "2022-12-31T00:00:00"^^xsd:dateTime .

The representation is rather poor:

• doesn't connect to the IFC property explicitly (although it duplicates it!)
• doesn't say it's quantity Length, the dimension vector, units, etc.
• doesn't relate to QUDT

https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/FinishCeilingHeight is the same: it doesn't relate to Height in any way.

My take:

• These are defects of specific BSDD data that we shouldn't be satisfied with. We should use all BSDD prop attributes, and when not enough we can add our own, eg:

@prefix ifc-prop: <https://identifier.buildingsmart.org/uri/buildingsmart/ifc-4.3/prop/>.
@prefix acd-prop <https://identifier.buildingsmart.org/uri/accord/bco/prop/>.

# BSDD stuff as per above, and then
ifc-prop:Height
  qudt:kind quantitykind:Height;
  qudt:applicableUnit unit:M, unit:MilliM. # BSDD also can attach units, but they're just string and single/multivalued is unclear
ifc-prop:FinishCeilingHeight
  skos:broader ifc-prop:Height.
acd-prop:ModularRoomHeight
   skos:broader ifc-prop:FinishCeilingHeight.

• these are bsdd:Property individuals. However, in semantic rendition of IFC data, it's better to use them directly as RDF props. Eg see below. (I've used LINDT specially formatted literals for simplicity: to avoid the need for intermediate node with unit, value)

<room>
   ifc-prop:FinishCeilingHeight "2.20 m"^^ucum:length;
   acd-prop:ModularRoomHeight "2.18 m"^^ucum:length.