search

Accord-Project / aec3po

AEC3PO: Architecture, Engineering, Construction Compliance Checking and Permitting Ontology
https://w3id.org/lbd/aec3po/
2 stars 1 forks source link

using BSDD for numeric props #28

Open VladimirAlexiev opened 1 year ago

VladimirAlexiev commented 1 year ago

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

https://github.com/Accord-Project/aec3po/blob/5fb6f7e2b8b9f0f208caeeab68461aa8b3c0dfcd/src/quantity_kinds.ttl#L49-L60

@beachtom , @EdliraK do you agree?

beachtom commented 1 year ago

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 commented 1 year ago

How are such specifics expressed in IFC?

beachtom commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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

maximelefrancois86 commented 1 year ago

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 commented 1 year ago

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:

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:

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`)
```ttl
<room>
   ifc-prop:FinishCeilingHeight "2.20 m"^^ucum:length;
   acd-prop:ModularRoomHeight "2.18 m"^^ucum:length.