Proposal for new IfcQualificationResource

[Moult]

Construction resources currently include materials, equipment, labor, and product (of which the definition of product is a little less clearly defined in my opinion). Missing is qualifications, such as prerequisite training or certification requirements to perform a task. This came out of a discussion with @billeast - here is an example given by him:

For example, you have to have an HVAC mechanic do the work, but they must be ASHRAE certified.

Perhaps @billeast can provide:

• A description of the proposed class
• Example usages (e.g. association with a task is one, what might others be? Can it be associated with a cost like other resources? Can it have a productivity rate like labor resource? Can it calculate utilisation like other resources? If these usecases don't apply to it, maybe there is a different location in the hierarchy for it to belong?)
• What predefined types it may have (e.g. certification, training, insurance, whatever?)

[billeast]

So first of all the issue is that there are more than the three standard resources needed for many jobs. For example, every steamfitter (at least in the US) has a unique stamp they use to certify the quality of every weld they do. There is a requirement in most US public contracts for the certification and stamp for each welder employed on the job to be submitted before that welder can start work. On the facility maintenance side, there are may requirements for mechanics/Technion's to be factory-trained or have a formal certification. This type of resource does not, however, have a quantity or duration. Only that the required qualification exists or does not exist.

[billeast]

Next to identify is that the project we're working on will simply use the label of the ConstructionResource to identify the type of resource (material, labor, equipment) with 'training' being a type of labor resource. The problem with this approach is that the objecttype should not be allowed to be used if the predefined type is present. Having an objecttype that is automatically overwritten based on the value of the predefined type sets up mis-matched data that cannot be corrected by end-users. I think this issue has a -much- wider scope that the initial use case suggests...