Check Uniqueness of all GUIDs

[Cudok]

I think about to generate an IDS file to check the uniqueness of all GUIDs in a IFC file.

Is this possible?

From my point of view it is not possible, because the ids schema is structured to check "only" information (properties, attributes and so one) which are related to elements, which are filtered by the Applicabilities. But I don't find an option to compare elements.

When this is not possible, maybe it could be a good feature of further version IDS?

[Moult]

This should be a responsibility of the validator, not IDS.

That said, uniqueness of other attributes (e.g. Name) is very, very, useful.

[atomczak]

In the early days of IDS, it was decided not to include certain checks within its scope. I wasn't around, but the decision was likely made to avoid requiring IDS checkers to examine the entire model or dataset at all times. With current IDS versions, it is possible to scan specific parts of models or focus solely on the changes (deltas).

[Cudok]

thx, thats helps a lot. So we have to implement this check without IDS. For bim2sim (https://github.com/BIM2SIM/bim2sim) we want to check the GUID uniqueness before we generate (semi) automatic simulation models.

[aothms]

Yes, so this is really a schema constraint (see the UR1 rule) so therefore it's not part of user-defined exchange requirements, this should apply to all ifc exchanges period.

ENTITY IfcRoot
 ABSTRACT SUPERTYPE OF (ONEOF
	(IfcObjectDefinition
	,IfcPropertyDefinition
	,IfcRelationship));
	GlobalId : IfcGloballyUniqueId;
	OwnerHistory : OPTIONAL IfcOwnerHistory;
	Name : OPTIONAL IfcLabel;
	Description : OPTIONAL IfcText;
 UNIQUE
	UR1 : GlobalId;
END_ENTITY;

ifcopenshell.validate will report on non-unique guids (not generally for all unique attributes unfortunately, but bespoke implemented). I assume other validators (e.g ODA / RDF IfcEngine) do the same.

[atomczak]

Validation Service (open source, from buildingSMART): https://validate.buildingsmart.org/ can also check that.

[andyward]

I'm aware that ensuring uniqueness of GUIDs may be a bit of a specific use case where there may be better schema level solutions - but do we have a roadmap item for IDS2+ to support the broader use-cases where people want to assert these kinds of domain-level requirements? For example "value-uniqueness" and potentially aggregate quantity requirements.

Some use cases:

For all IfcSpace entities, the Name attribute must be unique
For all IfcSensor entities, the AssetIdentifier property must be unique
For all IfcSpace entities (matching some classification) the total GFA must be > 1000

Uniqueness is probably the common omission we come across from clients looking at IDS to check their models. The latter is less common but not unheard of.

Proposal

Just looking at 'uniqueness' tactically/naively in a future IDS, it feels like we could do something like this:

from the Ids1.0 Schema

<xs:complexType name="idsValue">
  <xs:choice minOccurs="1">
	  <!-- place for potential additional rules for idsValue -->
	  <xs:element name="simpleValue" type="xs:string" minOccurs="1" maxOccurs="1"/>
	  <xs:element ref="xs:restriction" minOccurs="1" maxOccurs="1"/>
          <!-- proposed addition -->
          <xs:element ref="uniqueRestriction" minOccurs="1" maxOccurs="1"/>
  </xs:choice>
</xs:complexType>

... where the uniqueRestriction type is the third idsValue constraint, which may have a schema to establish an optional 'scope' etc. We might even create a specialised <idsAggregateValue> to allow it to be targeted more tactically.

Usage in IDS specs

<specification name="For all IfcSpace entities, the Name attribute must be unique" ifcVersion="IFC4">
      <applicability maxOccurs="unbounded">
        <entity>
          <name>
            <simpleValue>IFCSPACE</simpleValue>
          </name>
        </entity>
      </applicability>
      <requirements>
        <attribute>
          <name>
            <simpleValue>Name</simpleValue>
          </name>
          <value>
            <!-- Name value must be unique -->
            <uniqueRestriction/>
          </value>
        </attribute>
      </requirements>
</specification>

This changes the verification 'predicate' to something like (C# but hopefully transferable)

// TrySetValue() attempts to add to the UniqueSetValues dictionary in the requirement, returning false if already present
var duplicates = applicableElements.Where (element => RequirementContext.UniqueSetValues.TrySetValue(SelectRequirementValue(element)) == false)

Appreciate this may change the semantic a bit, given the requirement applies to the set of applicable elements not the individual element. It would probably help to have a to allow easy identification of set based requirements vs element level. But (speaking as an implementor) it feels like it would actually be pretty simple to implement for this narrow but useful (uniqueness) use case.

Aggregates

My third use case (GFA > 1000) is more complex and probably another topic. It feels like these are a broader set of requirements that would need to be modelled via a more sophisticated Aggregates model:

For all IfcSpace entities, the Name attribute must be unique = (GroupBy: Name, Aggregate: Count(_), Constraint: 1)
For all IfcSensor entities, the AssetIdentifier must be unique = (GroupBy: Pset.*/AssetIdentifier, Aggregate: Count(_), Constraint: 1)
For all IfcSpace entities the total GFA must be > 1000 = (GroupBy: nil, Aggregate: Sum(Pset_SpaceCommon.GrossFloorArea), Constraint: minExclusive=1000)

Obviously this starts to introduce extra complexity (arbitrary complex Expressions etc) but we could presumably start simple and have some implementor agreements (like we do with Regex patterns)

Thoughts?

[atomczak]

@andyward, that's a nice proposal to be considered for the scope of the next version of IDS, thanks! Your GFA example is a bit similar to value comparisons: #320 We will go through this idea's page when we get to that.

Answering the question about the roadmap, we plan to update the technical roadmap this year to answer these questions. There is a plan for the IDS1.1 update that adds backward-compatible changes. All major changes and IDS scope review are to be addressed with IDS2, which is planned to be aligned/integrated with the IFC5.