don't like "Design"

[VladimirAlexiev]

To @EdliraK @beachtom @maximelefrancois86 (Pan doesn't seem to be in this git proejct?)

In my examples https://github.com/Accord-Project/bcrl/blob/main/FI-accessibility.yaml I have:

• objects that may have components (eg Ramp has Landing) and features (eg Ramp has Surface)
• properties (quantitative or qualitative) that are compared to constants

In the current ontology there is a lot of "Designs", eg

<ramp> aec3po:hasDesign <design> .

# Define the property design of the ramp
<design> a aec3po:PropertyDesign ;
    aec3po:hasDesign <ramp_design> .

# Define the values for the ramp design
<ramp_design> 
    aec3po:hasDesign <structure_design>;
    aec3po:hasDesign <width_design> ;
    aec3po:hasDesign <landing_design> ;
    aec3po:hasDesign <gradient_design> .

<width_design> a aec3po:PropertyKindDesign ;
    aec3po:hasProperty <hasRampWidth> ;
    aec3po:hasValue 900 ;
    aec3po:hasQuantityKind <MilliM> ;
    aec3po:hasComparisonOperator aec3po:ComparisonOperator-ge .

<hasRampWidth> ## UNDEFINED

I don't even know how a design can have a design, and how a property can have a design.

I have several objections to this word:

• Regulations are sometimes checked on as-built structures. Then the word "design" isn't appropriate since it's "constructed"
• Some properties can hardly be called "designed". Eg if you have an Exception "doesn't apply to houses built before 1950", can you call "year built" a "design"?
• I think it's necessary to first describe components and features before we talk about the properties of these sub-components. We shouldn't attach property checks directly to higher-level objects

[AmnaKRDB]

This has been revised. The full example is now available here https://github.com/Accord-Project/aec3po/blob/main/examples/Finland/FI-accessibility-AEC3PO.ttl