Hello, I have seen in Archicad, that there is an attribute TAG:
Does anyone know what that is, and what is it for?
Hello, I have seen in Archicad, that there is an attribute TAG:
Does anyone know what that is, and what is it for?
The Tag attribute is located on IfcElement https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2/HTML/link/ifcelement.htm
The tag (or label) identifier at the particular instance of a product, e.g. the serial number, or the position number. It is the identifier at the occurrence level.
As I’ve seen it, an authoring application can use it to store it’s internal identifier for the element (many applications use a GUID which can be encoded to the GlobalId attribute, but others use an integer or other key). Often the application guid might be repeated without encoding in the tag. It might also be used to store a Project Identifier for the element.
There is a huge difference if it contains a user-controlled value (e.g. ARCHICAD Element ID or Revit Instance Mark) versus a software-controlled value (e.g. GUID or entity index/number). Unfortunately, based on a rather open description, the usage of that particular attribute differs between software.
A project-specific instance code (e.g. for the FMIS system) = should be user-controllable.
A serial number = defined by a manufacturer - should be user-controllable.
But this is something else than a guaranteed unique identification = should be software-generated (hence GUID, UUID).
Name and Number are good examples of user controllable attributes as well. Very important identification for the user!
Thank you very much. In this case, it’s automatically generated by Archicad, but it could be modified by users. It’s an IfcIdentifier (thanks for the link). As it is said, “it allows an individual thing to be identified”. But we already have the GlobalId (that can’t be modified) for that purpose. I don’t see why this attribute could be useful. I’m not sure if I suppose export it in an Ifc (I am exporting it now).
You should fill it out if the receiver of your data requires it. Otherwise, it makes no sense bothering with it. As you can see from the official documentation, it is an attribute that allows serial or position number of products to be transferred. Might be that the element you are considering it for does not have either of those.
Thank you all!
This opens a paradox that I’m sure you discussed about it a lot
GUID vs Namespace?
Those three are really good ideas, but will cause a big and inefficient database (especially in SQL-based databases)
Personally I don’t know GUID is good enough or not? When I see some companies like Pixar dropped it from their schemas/systems
Can I propose renaming this attribute from “Tag” to “AuthoringId” or similar? That would prevent confusion. Other uses of it can be stored elsewhere (Name/Reference/custom pset).
Hello, Moult.
Although it seems a good idea, but still using “AuthoringId” could also be confusing when certain Software because they map OOTB their internal also-called ID to, i.e., IfcName value. (the case of Graphisoft Archicad when using Element ID. The Archicad Unique ID, in the other hand, goes to Tag).
David
Hmm, compare current state of affairs:
Name
: stores internal ID for ArchiCAD, stores funny concatenation of family name and type name and internal ID for Revit, etc … Mostly Inconsistent, Duplicates information (i.e. from Tag
), Mostly Incorrect (i.e. if you tag an element on paper documentation, it should, but does not match the IFC Name
- but some vendors get it right)Tag
: Vendors relatively consistently store their internal id. Some ignore it. A few do something totally different. A few vendors are inconsistent, Confusing attribute name, Duplicates information (i.e. sometimes duplicates Name
field).… with proposed state of affairs:
Name
: three disadvantages of mostly inconsistent, duplicate information, and mostly incorrect stay unchanged.AuthoringId
: disadvantages decreased to two: a few vendors do strange things, and it may duplicate information, the “duplicates information” disadvantage is less, as it is now explicitly the source of truth in the spec for the authoring ID.If “Tag
” / “AuthoringId
” is to be used explicitly for exporting the authoring tool’s internal ID (and therefore to be used for keeping a trace to identify the original elements in the authoring tool) then it should be included in other IFC classes as well, like IfcGrid
, IfcLinearElement
, IfcStructuralItem
, etc.
(the fact that it’s not, probably indicates that this wasn’t the intended use)
That’s a good point - the original use is ambiguous. The name is ambiguous, and the description is ambiguous. What do you think about deprecating the attribute and if vendors want to continue to store their authoring ID, they can use a pset?
Or make it clear once and for all and use it for the “internal ID” from the Authoring software? That is what Solibri displays as “BAT ID”.
@daviddelven Beware that the “Element ID” from Archicad is a user-editable string (could be anything) and it totally depends on the IFC export settings whether this Element ID gets mapped via a rule to the IfcElement.Tag attribute or not.