Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UUID's vs unique names #10

Open
jbrouwerdigibase opened this issue Jan 10, 2025 · 2 comments
Open

UUID's vs unique names #10

jbrouwerdigibase opened this issue Jan 10, 2025 · 2 comments

Comments

@jbrouwerdigibase
Copy link

When I look at it the most basic IFC5 object is this:
{
def: string,
type: string,
name: string (unique),
attributes: [],
children: [],
inherits: []
}
where "name" is the unique identifier for the object like in USD.

In our industry we have so many different types, for example things that have the same properties/relationships but not the same geometry, but do benefit from type grouping by readable name. Although in theory just using unique naming as identifiers looks so logical, I do think our industry will benefit more from a seperation between readable name and identifier.

{
def: string,
type: string,
globalId: string (unique),
name: string (not unique),

attributes: [],
children: [],
inherits: []
}

For myself I worked around it for now by appending the UUID after the name, but that reduces readablility.

@tomi-p
Copy link

tomi-p commented Jan 10, 2025

I have the same pain. My workaround has been to use the "comment" field to include an understandable name. Alternatively, I used an understandable name in the "name" field to make it unique within my own test. The latter is, of course, the wrong way to create unique identifiers, but with long codes alone, I find it challenging (impossible) to figure out the different components and their interrelationships.

In principle, the exchange format does not need to be human-understandable. However, one argument against the STEP format has been that it is difficult to understand. In this respect, IFC5 does not improve the situation. A small enhancement could be the adding of a plain-language name for each object. The downside is that it increases the file size.

@atomczak
Copy link

As the property group from the hacakthon last week, we tried to solve this with a combination of a readable code containing a namespace, hashed to UUID for efficient and unique identification, and optionally aided with a displayName:
https://github.com/buildingSMART/IFC5-development/blob/46281feb2a917fb4f8d8db8cb35f3c8c1ce53444/Example%20-%20properties/properties.ifcx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants