Add an origin information to GUID's

[klacol]

In #8 the notation of the GUID was discussed and changed for the future. I want to add another aspect to this.

As we know, a GUID is unique, regardless, where, when and who the GUID hat created. So it can be used to identify things in a secure way.

But sometime, the GUID is also used as a key, that can lead to more information, than the information, that is stored in an IFC file.

Imagine, you have a GUID for a door in an IFC file. The file contains some information about the door. But often, the system, that has generated the file has more information about the door, than the parts that where include while creating the file.

Now, I want to look up this additional information (e.g. in an external database) ; and yes, the GUID is good for that, because it identifies also the door in the database.

But in which database? Who is the owner/creator of the database that has created the GUID?

Let imagine whe have a publisher that can be identified by a PublisherCode and this publisher has create the GUID in a database that can be identified by a SystemCode.

We could have something like this:

PublisherCode:SystemCode:GUID

e.g. SAP:SYS1:21b1b279-269f-4df5-9a5f-455d65c0e4f1 or BSI:BSDD:25abe353-29f6-45e9-b8ba-07a7daa2ac33

What do we win: We get the ability to resolve all parts of the models to the origins. This would allow the creation of models that are made up out of severall source, not only one.

What do we loose Now, we woul loose nothing, since we want to change to GUID notation, which would be a breaking change. A new implemention could impelent such an GUID-resolver easily.

Schema impact: We would have to define the notation of the resolvable GUID string.

Instance model impact: Breaking change, as #8 is also a breaking change

Backwards compatible: no

Automatic migration possible: yes

[Moult]

I disagree. These are two different fields, they should not be concatenated into a single attribute. And, if it is stored, why should it be stored inside the IFC file? What if it is a relative URI?

You also assume that the IFC wants to be able to relate to an external file. That's what IfcExternalReference is for. In fact, in practice most of the time it is the other way around - other documents then refer to an IFC file.

[GeorgDangl]

I agree with @Moult, a GUID itself is a key. If there's the need to associate other metadata along with it, it should be in separate fields. This would ensure that the solution stays flexible and doesn't have to have additional processing logic for handling identifiers.