search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Reuse of externally defined information concepts #53

Open jetgeo opened 4 years ago

jetgeo commented 4 years ago

Reusing externally defined concepts is a good practice for information modelling. The IFC model is a complete standalone model, with specifically defined primitive datatypes and datatypes for date and time, measures, geometry and more. Such concepts are also defined as general IT concepts (XML schema, basic ontologies) or as specific concepts for, e.g., geospatial information (ISO/TC 211 and OGC). Instead of defining specific abstract concepts for IFC, existing and more general concepts should be reused. By reusing already defined concepts, integration with other domains would be easier to achieve. Note: not all concepts are externally defined, e.g., ISO/TC 211 geometry concepts do not handle swept and constructive solids. Specific concepts needed for IFC should still be internally defined.

The move towards using UML for modelling of IFC is a good opportunity to look at this issue. We have discussed the issue of integration with some core concepts from ISO/TC 211 standards in a newly published article: https://www.mdpi.com/2220-9964/9/4/278.

SergejMuhic commented 4 years ago

The IFC model is a complete standalone model, with specifically defined primitive datatypes and datatypes for date and time, measures, geometry and more.

This is not exactly true as ISO10303 contains more than one part.

jetgeo commented 3 years ago

Yes, ISO 10303 contains many parts, and IFC applies primitive EXPRESS datatypes. But the IFC model also defines a range of specific primitive datatypes (e.g IfcInteger, IfcReal) and datatypes for time (e.g. IfcTime, IfcDate), measures (e.g. IfcAreaMeasure, IfcLengthMeasure) and geometry (e.g. IfcCurve, IfcSurface) that are defined in more general models outside IFC. Interoperability with other domain models would be easier if the IFC models reused these external concepts instead of defining special internal concepts.

berlotti commented 3 years ago

Hi @jetgeo It is the exact intent of IFC5 to (re)use these kind of industry accepted standards, instead of bespoke, self made solutions. Thank you for your contribution. This is a really good one!

Moult commented 3 years ago

Something to think about is that although the underlying primitives might be OK, sometimes there may be a need for an abstract layer to further restrict the character set. For example, non-printable characters in IfcIdentifier and IfcLabel. Should we really accept line breaks these data types?

https://forums.buildingsmart.org/t/non-printable-characters-in-ifc-string-data-types/3497

Scenario: Bob is not a computer guy. Bob is told to fill in a spreadsheet which will then be imported into a BIM IFC dataset. Bob loves the copy paste command from various sources.