I suspect relationships were adopted due to the strong dependency on EXPRESS and STEP in design. Having a class serialized to STEP with lots of direct attributes isn’t ideal as every single attribute needs to be noted (even if null/empty).
I’d like to see many relationships made obsolete, although it might be that xml (or something similar) should be a dominant serialization format for this to happen.
Minimum I’d like to see the class they inherit from be changed from IfcRoot particularly so that Global Ids aren’t manufactured in many authoring applications.
@ReD_CoDE, what would be the benefit to only have such leaf-node classes? Isn’t it the purpose of object-orientation to use inheritance to share common relationships and functionality?
Agree to @jonm, that many of the relationships could be combined and simplified, e.g why having specific relationships to attach classification, documentation and library references - it should be only one to expand the definition of a class by additional alphanumeric content. But it needs to be discussed also in line with backward compatibility issues. And such relationships don’t require a persistent guid, since they are created for serialisation, and do not hold own and persistent information.
I’m not a programmer, but because of our existing startup I have to learn the existing solution as much as I can, at least general things
So, as I know generally, if a data structure has a “structured form” it’s better use “relational databases” --> SQL
If the data structure is “complex and unstructured” form then is better use “Object-Oriented database”
So, the IFC data structure is complex? Unstructured?
If not, why was it originally developed based on Object-Oriented approach?
So I think “SQL” would be a better choice for schema (It’s fast, has better performance, is clear and doesn’t cause headache and lot of mistakes, etc)
But all “information systems” would be “Object-Relational Systems” which have a “Relational database” and “Object-Oriented frameworks”
"While object-oriented and relational design share some common characteristics (an objects attributes is conceptually similar to an entities columns), " - So, what this means that IFC is possible to be modelled both ways, the EXPRESS schema allows it. For exchange a file format makes sense as you can generate a physical file that you exchange. For archiving data, databases make sense (SQLite being one of them). It all depends on (as always) context. If you read the IFC formats page on the bSI technical site, it even mentions SQLite as a possible format.
This statement “So I think “SQL” would be a better choice for schema” is not in context though. The schema is in EXPRESS (as of late also UML). These are data modelling languages. One of their representations is SPF, another one can be SQLite or others …
As I have asked @jonm above, what if I want to track changes of a particular relationship? In that case an ID and owner history suddenly make sense. As we are talking about IFC representing a the entire life cycle, I think we should not be to hasty with removing this.
“So, who will build IFC SQLite?” - Whoever needs it. The same as SPF. Companies who wanted to exchange data got themselves certified and are now using it.
“Also, as you say an ID, but that ID should be GUID/UUID?” - Yes. Could be anything else from my point of view, but as UUID ensure universal uniqueness, I think it is quite well suited for the task.
“It seems that GUID/UUID is an old-fashioned approach today” - GUID/UUID is not an approach, it is a " A universally unique identifier ( UUID ) is a 128-bit number used to identify information in computer systems. The term globally unique identifier ( GUID ) is also used, typically in software created by Microsoft." - Wiki
Also, the discussion is not about dropping UUID as the problem lies in that they are not unique. Relationships might not even need them.
If you say old-fashioned, any proposals on how do uniquely identify an instance?
Hi @sergej - I did not argue to remove the capability of holding a UUID for relationships - but it should not be enforced in any case and thereby leading to “fake” UUID. I think it is better to keep UUID for relationships optional on schema level and only impose it to be mandatory, if a particular implementation/exchange scenario requires it
I’m trying to figure out whether what I’m asking for here is a good idea.
The obvious strategy to do this would be to just flip the inverse attributes to attributes. This would add a bunch of new attributes to entities, but would remove the relationship entities entirely. In implementations this would make it more obvious what types of relationships are allowed as they would manifest as properties, but it would (I think) have a negative impact on memory usage as constructing objects with these new properties would allocate a larger amount of memory, much of it for properties that may remain null. Of course, these properties would be reference types so each one would be eight bytes in C# (on 64 bit systems). Thinking of it this way, it’s possible that relationships were originally designed for memory-constrained systems.
I tend to agree Ian, I’d suggest from my own understanding that the choice of express as a serialization format might have led to a preference for inverse relationships. Optional relationships would then add a lot of attributes to each line, and using an isolated relationship then is more reliable over different versions of the schema for inherited relationships.
If more modern serialization becomes common, then we might well advocate for the removal of many relationships.
Probably the most used relationships (looking at you IfcRelDecomposes) could be done without the intermediate class. But, there is some nuance to consider. Let us look at IfcRelAggregates vs IfcRelNests. IfcRelAggregates.RelatedObjects is S[1:?] and IfcRelNests is L[1:?]. So, IfcRelAggregates requires no order in the list of Objects, whereas IfcRelNests requires order. Some relationships are more complicated with their own PredefinedTypes.
So, as always, it is not easy but I tend to agree that relationships should/could be reconsidered. It would make the implementation of the IFC Schema as an object database more straight forward.
yes, the reason to use objectived relationships (or relationship classes) in the first place was coming from:
the ability to strip away unneeded relations from the serialised entitities in an IFC (i.e. STEP file format). This enabled a good way to define MVDs.
seeing other serialisation formats (xml, json) or class diagrams (UML) this objective could be satisfied in a different way. So this could be seen as part of a modernization effort.
N.B. when publishing the IFC XSD Schema, already some inverse relationships are inverted to become XML elements.
It would make the implementation of the IFC Schema as an object database more straight forward.