Pieter Pauwels

Okay, so maybe we can make that gentlemen's agreement an explicitly written out agreement (maybe on the README cover page of this repository?)? The late binding boundary line can be...

> For me, it is more, to find a way to load the sub classes of IfcProduct from different sources and the today-subclasses of IfcProduct in ISO 16739 could be...

+1 seems like an easy fix. If possible, we should resort to SETs (no order), instead of LISTs. Not possible in this case, so that should be `IfcMaterialLayerList` and `IfcPolygonalFaceList`.

There seem to be two issues in one here (too many relationship; many-to-many vs. direct relations). I suggest to split the issue in two. In my understanding, Relations are currently...

One to many relations don't need an intermediate object. They just need an attribute pointing to a LIST or SET (or BAG or ARRAY). So... the RelatingObject and RelatedObjects from...

@HerbertDobernig... with the best of understanding (same discussion happened at length in the W3C LBD group), but... The most flexible datamodel has `things` that are related through `relationships`, have `IDs`...

> I am an advocate of identifiers because they allow segmentation of information as used in > > * distributed and federalized CDEs > * database normalization towards "5 NF"...

If the proposal to maintain `IfCOwnerHistory` in #16 is followed, then this entire objectification discussion is obsolete. If I am not mistaken (typing on a mobile device), each `IfcRelationship` is...

> @pipauwel > I would like to better understand your arguments and your viewpoint. > What consequences in XML, JSON, and RDF do you expect? I don't want to go...

I tend to translate SELECTs to a subtype and supertype hierarchy. This is of course extra difficult if subtypes of one type are 'LIST' and 'WALL' and 'INTEGER'. A more...