Moult
commented
2 years ago Proposal for classification association:
It sounds as though the only parameterisation is in IfcDistributionControlElement. The relationships are all about external references.
Edit: evidence is because in IFC2X3 the original usecase was an attribute known as ControlElementId with this description "The ControlElement Point Identification assigned to this control element by the Building Automation System"
There are three types of external references (I copy pasted key bits of existing doc descriptions):
- Classifications: ... arrangement ... into a class or category according to a common purpose / characteristics... taxonomy, or taxonomic scheme, arranged in a hierarchical structure. A category of objects relates to other categories in a generalization-specialization relationship. Therefore the classification items in an classification are organized in a tree structure. A classification system declared may be either formally published, or it may be a locally defined method of classifiying information.... and as per chapter 3: classification: categorization, the act of distributing things into classes or categories of the same type
- Documents: yeah, not a document.
- Library: An IfcLibraryInformation describes a library where a library is a structured store of information, normally organized in a manner which allows information lookup through an index or reference value.
I disagree with the current usage of classification. IP addresses, MAC addresses, BACnet Object Identifier in a Building Automation System etc is not a hierarchical tree that classifies information - it may be a tree that signifies network setup, but not the information you are referencing in the network. So the whole concept of "tokens" in a classification system which denote hierarchy is not meaningful. This statement is makes no sense in terms of information to a user: "oh this element is on 127.0.0.1 so the parent classification of similar elements must be 127.0.0".
The problem is that the alternatives aren't very good either. Documents are not correct. It's clearly a different concept.
By process of elimination we should use a library reference - in the original usecase, a Building Automation System would be the external data library, and you'd refer to a key within that system. But there are still problems:
- The concept for library information seems to only talk about a library as a revision control server. Its specifications are rather questionable and implementation is undoubtedly rare.
- The entity description for IfcLibraryInformation seems pretty good until this line "In a broder sense, IfcLibraryInformation includes the meta data for capture the revision information when checking in library and other data into a revision control system." which again talks about revision control.
That said, I still think it's good to keep classification of objects separate from what I call "How elements are linked to external systems". I'd propose introducing formal concepts for library references, and rewording the library descriptions so that a revision control system is just one example of the systems you can link to, but BACnet et all are good examples of other systems.
So the parameterisation would disappear, and be merged into the docs as guidelines in IfcLibraryReference or in the newly added Library Association concept.
I actually asked this to @jmirtsch in the past: "How would I associate an IFC element to say a Brickschema dataset"? After looking at the three external reference types, we came to the same conclusion.
Thoughts?
aothms
NickNisbet
TLiebich
Aggregation
Two issues here:
Solution:
Axis 2D Geometry
Solution:
Body Geometry
Issues:
Solution:
Body Tessellation Geometry
Issue:
Solution:
Classification Association
Issues:
Solution:
Constraint Association
Issues:
Constrained Attribute=does not relate to a defined term it seems.Solution:
Control Assignment
Issue:
Solution:
Element Nesting
Issue:
Solution:
Group Assignment
Issue:
IfcGroup -> IfcRel -> IfcProduct. This is wrong in two ways (a) I think it should be reversed (b) the entity on the right now should not be IfcProduct (IfcGroup isn't an IfcProduct) but IfcObject probably.Solution:
Material Constituent Set
Issue:
Solution:
Material Layer Set Usage
Issue:
Solution:
Material Profile Set Usage
Issue:
Solution:
Object Nesting
Issue:
Solution:
Object Typing
Issue:
Solution:
Note that this will also be reflected in the entity where rules that are derived from the ObjectTyping concept.
Port Nesting
Issue:
Solution:
Product Local Placement
Issue:
Solution:
Product Placement
Issue:
Solution:
Property Sets for Objects
Issue:
Solution:
Quantity Sets
Issue:
Solution:
Spatial Composition
Issue:
Solution:
Spatial Container
Solution:
Spatial Containment
Issue:
Solution:
Alternative solution:
Spatial Decomposition
Solution:
Type Body Geometry
Issue:
Solution: