search

Accord-Project / aec3po

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

basic example of checking a property against constant #10

Closed VladimirAlexiev closed 1 year ago

VladimirAlexiev commented 1 year ago

The atomic part of RASE consists of "building object O's property P is compared using comparator C to constant value V expressed in unit of measure U".

I've read the definitions of these terms aec3po:NumericalCheck, aec3po:PropertyDesign, aec3po:hasValue, aec3po:hasComparisonOperator and cannot figure for the life of me how they connect.

The example below is more understandable, but has

And I don't think it corresponds 100% to the class and property definitions (have you guys checked this?).

I think we should start by cleaning and finalizing this and more examples, THEN make the ontology to fit. https://github.com/Accord-Project/aec3po/blob/5fb6f7e2b8b9f0f208caeeab68461aa8b3c0dfcd/examples/Ramp_Example.ttl#L74-L79

beachtom commented 1 year ago

I am not sure what we can do with this - but I think we will quickly outstrip the level of complexity we can achieve here - thus my suggestion of the expressions in T2.3.

Unless we want to take the decision to represent simple in this way and then more complex in expression language

AmnaKRDB commented 1 year ago
  • hasRampWidth is not defined,

Well spotted. This is has been now defined as a Property.

AmnaKRDB commented 1 year ago
  • aec3po:hasQuantityKind <MilliM> should be unit not QuantityKind!

It has been defined in the core ontology as QuantityKind. Do you think that this needs to be updated in the core ontology as QUDT: Unit, and afterwards it will be updated here?

AmnaKRDB commented 1 year ago
  • how are hasRampMaxGradient hasRampLowerLandingElev hasRampUpperLandingElev hasRampIntLandingLenght hasRampIntLandingElev hasRampRampIndoorCondition related?

They have been all defined as properties of the PropertyKindDesin .

beachtom commented 1 year ago

I am still not coinvinced we should be defining "hasRampMaxGradient" or properties like that in the ontology. They are very problem specific and i feel the ontology should focus on more generic concepts.

AmnaKRDB commented 1 year ago

I am still not coinvinced we should be defining "hasRampMaxGradient" or properties like that in the ontology. They are very problem specific and i feel the ontology should focus on more generic concepts.

I agree. These properties have been defined by the expert due to the problem of matching between the IFC element properties and the properties defined in the regulations.

EdliraK commented 1 year ago

I agree, Tom and from the start, I have been resisting and even rejecting this level of binding from the ontology but the push was to try it. No harm to use it just for the ontology examples (even to provide it's not efficient) but forward we should stick to representing this part with your language as you did in the Estonian example. I quite like that one.

beachtom commented 1 year ago

Great!

AmnaKRDB commented 1 year ago
  • aec3po:hasQuantityKind <MilliM> should be unit not QuantityKind!

This has been corrected by qudt:hasUnit unit:MilliM

AmnaKRDB commented 1 year ago

The example below is more understandable, but has

  • mistakes, at least two:

    • hasRampWidth is not defined,
    • aec3po:hasQuantityKind <MilliM> should be unit not QuantityKind!
  • and gaps
  • how are hasRampMaxGradient hasRampLowerLandingElev hasRampUpperLandingElev hasRampIntLandingLenght hasRampIntLandingElev hasRampRampIndoorCondition related?

The full example has been revised and the new version is available here for your review https://github.com/Accord-Project/aec3po/blob/main/examples/Finland/FI-accessibility-AEC3PO.ttl