Proposal: No line numbers in IFC.JSON-4

[janbrouwer]

https://github.com/IFCJSON-Team/IFC.JSON-4/tree/master/Documentation#25-identifiers Line numbers are not part of the IFC4 schema, only for the SPF implementation, so I would not add them to the IFC.JSON-4 implementation.

I propose to only allow references for objects that have an "GlobalId" attribute, all others relations need tree-nesting for as long as the "GlobalId" property is not added tot the entity.

Also see decision on NextGen-IFC: https://github.com/buildingSMART/NextGen-IFC/issues/44

[pipauwel]

I think we need to be more specific here. I am absolutely in favor of dropping the line numbers in JSON, and then using the GlobalId attribute for referencing when it is available. We could include items in a tree if they do not have a GlobalId. Yet.... quite some data does not have a GlobalId. For example, IfcOwnerHistory objects do not have a GlobalId. Also the GeometricRepresentationContext does not have a GlobalId. If those are not cut and referenced, they will be repeated at length in the JSON serialisation. So it has quite some impact on the length of the JSON file.

We could suggest here to simply add a GlobalId to all elements that do not have it yet? Or for some critical elements? In any case, I think we need to evaluate this decision a while longer.

[devonsparks]

Just one other thought for consideration:

I'd agree the entity IDs are an artifact of the STP serialization and not a requirement of IFC proper. That said, if IFC is looking to support STEP 3 (confirmed?), we may want to consider their value for any backwards compatible flavors of IFCJSON.

The entity IDs in the IFC file identify the vertices of the IFC graph local to the STP file. For most of history, this was the best we could do. Every IFC was a universe unto itself with no way to reference IDs across files. That changes with STEP, Edition 3. The introduction of REFERENCE and ANCHOR sections allow an IFC-STP file to associate local entity IDs (e.g., #16) with remote URIs, and to expose local entity IDs, (e.g., #64), as URI fragments. This is a big deal for distributed workflows because it means, in principle at least, that IFC-STP files can form distributed graphs linked over the open internet. The STEP, Edition 3 standard uses entity IDs to support encapsulation of public and private graph vertices. If we choose to abandon them in IFCJSON, but wish to support STEP 3 in future IFC releases, is there an alternative mechanism to achieve the same end? Just food for thought :)

[Moult]

Ideas for the JSON equivalent of STEP anchors and references could be borrowed some one of the hypermedia conventions for JSON like HALJSON or JSON-LD.

Just my $0.02 :)

[devonsparks]

Hey @Moult

I was thinking along these lines too. Considering the group has been targeting JSON Schema, I thought HyperJSON Schema might be a possible option here. An almost backwards compatible approach with the existing IFCJSON schema would be to elevate the object array to a HyperJSON Schema "links" attribute. Then every object in the array implicitly has an array index that could be used as its IFC ID, without having to declare it. Two catches to this I don't yet have answers for:

1. We'd need some way to reference other entities by this ID. I haven't looked at the existing IFCJSON schema closely enough to know what this might break.
2. Version of IFCJSON Schema I've seen rely on nested objects. This implies every object no longer has a unique array index, and you'd have to use something like JSONPointer to identify nested nodes. This starts to add enough complexity to the graph traversal as to make me question whether it's the right approach.

In any case, it would be interesting to explore how STEP, Edition 3's new Anchor and Reference features might map to JSON-based hypermedia formats. Would love to hear if you have specific ideas here. I have some notes - will try to clean up and share out as soon as I can.

Thanks!