When property location matters

The same fact can appear in different places in a building model. Sometimes a requirement only cares about the fact. Sometimes it also requires one exact place. Axioval supports both choices.

Think of it like asking for a book:

• Any shelf is fine: find this book wherever the library stores it.
• One shelf is required: find this book in the reference section.

In technical terms, Axioval separates property identity from container qualification. Property sets are real relationship objects in IFC, but their names do not need to become the universal identity of a property.

Canonical property identity

A vocabulary defines the property once:

Show the property definition

["axioval:example.ifc.load-bearing"] = new Definitions.PropertyDefinition {
  id = "axioval:example.ifc.load-bearing"
  name = new Types.LocalizedText { default = "Load bearing" }
  valueKind = "boolean"
  externalNames {
    new Definitions.ExternalName {
      typeSystem = "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3"
      name = "LoadBearing"
    }
  }
}

The definition is not nested in a property set. Its stable ID can be reused by selectors, templates, and instances.

Loose reference: property matters, container does not

Show the loose reference

new Values.PropertyReferenceValue {
  property = "axioval:example.ifc.is-external"
}

An adapter resolves the external name and traverses the model's native relationships. The property may be found in any supported container.

Implementations must define deterministic conflict behavior. If the same canonical property resolves more than once with incompatible values, they should return a conflict. They must not choose one silently.

Strict reference: membership is part of the requirement

Show the strict reference

new Values.PropertyReferenceValue {
  property = "axioval:example.ifc.load-bearing"
  propertySet = "axioval:example.ifc.pset-wall-common"
}

Now both facts are normative:

1. the property is LoadBearing; and
2. it is related through the external container mapped from Pset_WallCommon.

A matching property in another set is not sufficient.

Use a loose reference whenUse a strict reference when

• the requirement is about semantic information, not authoring layout;
• exporters legitimately place equivalent properties in different sets; or
• a project mapping layer already canonicalizes sources.

• delivery requirements mandate a standard property set;
• interoperability depends on exact container placement; or
• the check is specifically auditing schema conformance.

Container-agnostic resolution is still fail-closed

When propertySet is omitted, an adapter must:

1. map the canonical property concept into the active model schema;
2. collect occurrences across supported property containers;
3. report missing when no occurrence exists;
4. converge type-correct occurrences only when their semantic values agree; and
5. report conflicting or invalid when values disagree or cannot be typed.

It must never accept the first same-named property it happens to encounter.

IFC relationship context

In IFC, an object is related to property definitions through IfcRelDefinesByProperties, and a property set groups named properties. Axioval does not erase that relationship. It lets each requirement decide whether the container identity is significant.

The official IFC 4.3.2 Pset_WallCommon documentation lists both LoadBearing and IsExternal as boolean single-value properties. That makes it a useful demonstration, not a reason to hard-code property-set ownership into the generic schema.