[IFC Tunnel][Geotechnics] Comments on taxonomy

[larswik]

• Having a class with only one subclass (HydroGeologyObservation=>WaterInflow) does not add much since this means that the two classes are essentially equivalent (all WaterInflows are HydroGeologyObservations and there are no other types of HydroGeologyObservations). Is this kind of structure really necessary?
• Having a lot of subclasses and a 1:1 relationship between class and Pset could potentially be simplified to keeping only the baseclass and having the "subclasses" being inferred by attaching Psets. E.g. applying Pset_Dilatometer to an object makes it possible to infer that the object (Test in this case) is actually a Dilatometer test.
• TrialPitTest is described as "A test carried out during the execution of a trial pit". However, TrialPit was removed as a subclass of Borehole. Does this mean that a TrialPitTest can be attached to a borehole (thereby making the borehole a "trial pit")?
• No "VoidBody" exists in the taxonomy. However, in IFC 4.3 there is an IfcVoidStratum. Is there no need to capture a void?
• The "SpatialGeoIntElements" shrinked to only GeologyModel, GeotechModel, HydroGeoModel and PhysicalPropertyDistributionModel. GeotechSynthesisModel and GeoHazardModel seems to have been removed. Is this "by design"?
• The "SpatialGeoIntElements" section was removed from the "Object types-Properties" tab (they are still in the "Object Type Hierarchy" tab, but changed slightly - see above). Does this only mean that you have found no properties for these concepts?
• GeotechTypicalSection (Book C) states "Reference to GeotechSynthesisModel". However, GeotechSynthesisModel was removed (see above)?

[patmclarin]

Having a class with only one subclass (HydroGeologyObservation=>WaterInflow) does not add much since this means that the two classes are essentially equivalent (all WaterInflows are HydroGeologyObservations and there are no other types of HydroGeologyObservations). Is this kind of structure really necessary?

Not necessary. Proposal: having GeoObservation instead of HydroGeologyObservation, GeotechnicalObservation and GeologicalObservation. The application for them is the same, just the information content is different and can be handled by different property sets. A Property like e.g. “discipline” can carry the info “HydroGeo / GeoTech / Geology” for filtering or relating to the right “GeoScienceModel” for linking Book A and B and specify the link in a model view definition.

[patmclarin]

_Having a lot of subclasses and a 1:1 relationship between class and Pset could potentially be simplified to keeping only the baseclass and having the "subclasses" being inferred by attaching Psets. E.g. applying PsetDilatometer to an object makes it possible to infer that the object (Test in this case) is actually a Dilatometer test.

Agreed. I recommend to distinguish only Lab Test and In-Situ test on the level of sub-classes and treat everything else with Psets. These classes can be linked to other objects like Boreholes, MappedZones and Samples

[patmclarin]

No "VoidBody" exists in the taxonomy. However, in IFC 4.3 there is an IfcVoidStratum. Is there no need to capture a void?

we would like to capture this condition. we could add it in Book B, as a GeoScienceFeature for example a GeoScienceVoid, to distinguish from man made caverns and excavations.

[patmclarin]

GeotechSynthesisModel and GeoHazardModel seems to have been removed. Is this "by design"?

No, we would like them retained. They need to be defined with the help of the Excavation and Support team.

[patmclarin]

The "SpatialGeoIntElements" section was removed from the "Object types-Properties" tab (they are still in the "Object Type Hierarchy" tab, but changed slightly - see above). Does this only mean that you have found no properties for these concepts?

These lines were not displayed because no properties were added yet. We need them and should add a common Pset with model author, model area (like a construction lot), project phase, submission date,… and maybe also specific ones for each model, like for GeotechModel e.g.: related geotechnical reports (describing the applied ground classification), model purpose (e.g. structural design for tendering). we will come with the completed list.

[larswik]

Having a class with only one subclass (HydroGeologyObservation=>WaterInflow) does not add much since this means that the two classes are essentially equivalent (all WaterInflows are HydroGeologyObservations and there are no other types of HydroGeologyObservations). Is this kind of structure really necessary?

Not necessary. Proposal: having GeoObservation instead of HydroGeologyObservation, GeotechnicalObservation and GeologicalObservation. The application for them is the same, just the information content is different and can be handled by different property sets. A Property like e.g. “discipline” can carry the info “HydroGeo / GeoTech / Geology” for filtering or relating to the right “GeoScienceModel” for linking Book A and B and specify the link in a model view definition.

Agreed! I propose a generic IfcGeoScienceObservation/GEOSCIENCEOBSERVATION instead of these three (Avoiding using only "Geo" as prefix since this may lead the thoughts also to Geography, Geospatial etc)

[larswik]

_Having a lot of subclasses and a 1:1 relationship between class and Pset could potentially be simplified to keeping only the baseclass and having the "subclasses" being inferred by attaching Psets. E.g. applying PsetDilatometer to an object makes it possible to infer that the object (Test in this case) is actually a Dilatometer test.

Agreed. I recommend to distinguish only Lab Test and In-Situ test on the level of sub-classes and treat everything else with Psets. These classes can be linked to other objects like Boreholes, MappedZones and Samples

Then I see this as a settled proposal!

[larswik]

No "VoidBody" exists in the taxonomy. However, in IFC 4.3 there is an IfcVoidStratum. Is there no need to capture a void?

we would like to capture this condition. we could add it in Book B, as a GeoScienceFeature for example a GeoScienceVoid, to distinguish from man made caverns and excavations.

I have added an IfcGeoscienceFeature/VOIDBODY in the model (parallel to e.g. FLUIDBODY, GEOTECHNICALUNIT etc)

[larswik]

GeotechSynthesisModel and GeoHazardModel seems to have been removed. Is this "by design"?

No, we would like them retained. They need to be defined with the help of the Excavation and Support team.

Ok, we'll need to come back to this then!

[larswik]

The "SpatialGeoIntElements" section was removed from the "Object types-Properties" tab (they are still in the "Object Type Hierarchy" tab, but changed slightly - see above). Does this only mean that you have found no properties for these concepts?

These lines were not displayed because no properties were added yet. We need them and should add a common Pset with model author, model area (like a construction lot), project phase, submission date,… and maybe also specific ones for each model, like for GeotechModel e.g.: related geotechnical reports (describing the applied ground classification), model purpose (e.g. structural design for tendering). we will come with the completed list.

These are still in the conceptual model and handled as predefined types for IfcGeoScienceModel

[aothms]

Having a lot of subclasses and a 1:1 relationship between class and Pset could potentially be simplified to keeping only the baseclass and having the "subclasses" being inferred by attaching Psets. E.g. applying Pset_Dilatometer to an object makes it possible to infer that the object (Test in this case) is actually a Dilatometer test.

I just wanted to quickly comment on this. It would entail that there are three ways then for subtyping in the schema. Entity / Predefined Type / Pset. There is no way to indicate that a Pset fulfills this subtyping role as opposed to a Pset with just complementary information. I would envision this poses problems for mappings to languages where typing is "cheaper" such as OWL or bsDD or mappings to native software. I'd personally prefer to have the predefined types in even if it is a bit of boilerplate.

[larswik]

Having a lot of subclasses and a 1:1 relationship between class and Pset could potentially be simplified to keeping only the baseclass and having the "subclasses" being inferred by attaching Psets. E.g. applying Pset_Dilatometer to an object makes it possible to infer that the object (Test in this case) is actually a Dilatometer test.

I just wanted to quickly comment on this. It would entail that there are three ways then for subtyping in the schema. Entity / Predefined Type / Pset. There is no way to indicate that a Pset fulfills this subtyping role as opposed to a Pset with just complementary information. I would envision this poses problems for mappings to languages where typing is "cheaper" such as OWL or bsDD or mappings to native software. I'd personally prefer to have the predefined types in even if it is a bit of boilerplate.

Thanks for commenting! I can agree with you in principle. The problem I saw is that I am not sure how fixed/agreed/static this list of tests is and also that it becomes very "boilerplate" as you say. But let's leave this one open.