IFC Modernization : Relationships

[jonm]

Refer https://forums.buildingsmart.org/t/what-would-you-like-to-see-most-in-the-modernization-of-ifc/

@ian

IFC relationships are built for querying in relational databases.

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.

The non-permanent GUIDs

At the moment the non-permanent GUIDs are “faked” to look like the permanent GUIDs, but there should not be any real need to do. This is only causing problems to regression testing , to diffs, etc. Therefore I’m proposing to have an null-GUID for non-permanent GUIDs i.e. ‘0000000000000000000000’ The only thing what we need to agree is that this particular GUID value has a special nature and does not need to be unigue in the IFC model. Many entities could share the same GUID. This would also …

[Moult]

+1.

Step one is to take them out of IfcRoot.

[ReD_CoDE]

Is it possible to develop a new IFC based on just end entity? I mean a much shallower tree.

For instance, IFC just has end entities like

IfcProject
IfcProjectLibrary
IfcSite
IfcBuilding
IfcBuildingStory
IfcSpace
IfcZone
IfcActor
IfcOccupant
So on

And drop all behind entities and just end entities (single entities) have types, rules, functions, and “simplified relationships”

Kind regards,
Ehsan

[sergej]

What if I want to track the changes in a relationship?

[ReD_CoDE]

Relationships will modernize and will be part of the “end single entity”

I’m thinking to a hybrid IFC schema which would be based on SQL and NoSQL.

In SQL part, I think we can use SQLite, but its “DATA TYPEs” has limitation and for geometries I’m looking for an alternative

[TLiebich]

@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.

[ReD_CoDE]

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”

http://www.cis.umassd.edu/~jbergandy/process/workflow/ana_desi/co_rdbom.htm

[sergej]

"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 …

[sergej]

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.

[ReD_CoDE]

So, who will build IFC SQLite? As we know, it’s “an unfinished project” inside the buildingSMART

Also, as you say an ID, but that ID should be GUID/UUID?
It seems that GUID/UUID is an old-fashioned approach today

[sergej]

“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?

[TLiebich]

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

[ian]

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.

[ReD_CoDE]

Ian,

Now, think about your idea in “SQLite”
And forget all Defined Types (130) which can be handled through SQLite data types

And even think about GUID/UUID and table_id
And a mix usage of GUID/UUID and table_id

[jonm]

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.

[sergej]

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.

[TLiebich]

re: @jonm & @sergej

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.

[ReD_CoDE]

http://resources.esri.com/help/9.3/arcgisengine/dotnet/2e097482-4f99-4224-896e-8027e6ab883e.htm