Background
These ideas are non-proprietary and in the public domain since 2007. They have been used in ISO12911:2010 onwards and so are free of copyright and IP. They are already embedded in mvdXML. They are logically complete and sufficient in the strict, mathematical sense.
see • Nisbet N, Wix J and Conover D. 2008. "The future of virtual construction and regulation checking”, in Brandon, P., Kocaturk, T. (Eds),Virtual Futures for Design, Construction and Procurement, Blackwell, Oxfordshire. doi: 10.1002/9781444302349.ch17 .
Use cases
The current proposal is very likely to be inadequate.
Its assumes a simple :
"if A1 then R1 R2" form, where A1 is the applicability and R1 and R2 are requirements.
However
a. There may be many serial applicabilities A1, A2 ..., each narrowing the scope, for example "external" "opening"
b. There may be many parallel selections, S1, S2 ..., each broadening the scope, for example "door" "window" "louvre"
c. There may be exceptions, E1, E2 ... escaping the rule, for example "tropical" "temporary structure"
d. Yes, there may well be multiple requirements R1, R2 ..., for example "waterproof" "windproof"
The following ideas were developed to make sure that rules can be BOTH human-readable AND machine readable.
These ideas are required in any situation other than the simplest . They allow the condensing of what otherwise have to be long, repetitive and error prone tables (see any buildingSMART spreadsheet MVD) into the most concise and unambiguous form possible.
Recommendation 1: A syntax should be used which accepts these.
Syntax:
Objective1 :=[ 1:4] Applicabilities &| Selections &| Exceptions &| Requirements (contain one upto 4 of)
Applicabilities | Selections | Exceptions | Requirements := [1:n] Metrics (contain one or more of)
Outline:
Objective {
Applicabilities {
Metric1,
Metric2
}
Selections {
Metric3,
Metric4
}
Exceptions {
Metric5,
Metric6
}
Requirements {
Metric7,
Metric8
}
}
Just to reassure you, the simple form is still simple!
Objective {
Applicabilities {
Metric1
}
Requirements {
Metrict7
}
}
Note on Terms:
'Objective' is synonymous with 'Rule'
'Metric' is synonymous with 'Test'
BUT Requirements is used much more specifically here compared to the previously posted proposal.
Recommendation 2: The syntax for the applicability, selection, exception and requirement Metrics should be identical.
Syntax:
Metric1 := Entity X | Property X | (more)
Example: Any window should have its light transmittance documented
Objective { Applicabilities { Entity IfcWindow } {Requirements { Property LightTransmittance }}
Example: Light transmittance should only be used on windows.
Objective { Applicabilities { Property LightTransmittance } {Requirements { Entity IfcWindow }}
More thought can be given to the number of different kinds of metrics we wish to support, including Level of detail and symbology.
Syntax:
Metric1 := Entity X | Property X | **Representation X** | (more)
Recommendation 3: The syntax in rule 2 should also include 'Objective' .
Syntax:
Metric1 := Entity X | Property X | Objective | (more)
This supports the recursive nature of plain language, meaning that ANY requirement document can be captured, including all existing MVDs. Any plain language document using any layout or language, using passive or active grammar, using simple or complex sentences, using normative or descriptive wording, can be expressed,
Recommendation 4: Make an explicit one-to-one mapping to IfcObjective and IfcMetric
The IfcConstraint model is already sufficient to do 'IDS' even if the step, ifcxml or ifcjson representations are wordy or obscure. But this means that any application that can read IFC can additionally read IDS without any further interface development.
Recommendation 5: Consider not needing IDS json or xml at all, just HTML with 'RASE' mark-up.
"All external doors windows and louvres shall have properties waterproof and windproof except in the tropics or in temporary structures."
This use of HTML also allows us to use tables of requirements efficiently. ( Github doesn't let me show how).