EXPRESS functions and rules, and their successors

[Airy59]

EXPRESS functions and rules may find an equivalent in OCL (Object Constraint Language, a part of current UML specifications) if the future IFC modeling language is UML. Similarly, if the future modeling language were OWL, SHACL shapes could at least partly take over those aspects of the current EXPRESS model.

The transition from EXPRESS to other formal languages (UML was, at least initially, considered the successor of choice) should also be considered in this light. At the time of writing, it seems however that the focus is on serialization (JSON vs. STEP) rather that model level. What would be the next steps?

[berlotti]

At the time of writing, the model level is defined using TypeScript. See here: https://github.com/buildingSMART/IFC5-development/tree/main/schema

[Airy59]

TypeScript would an interesting idea : a model wholly expressed in TypeScript that is not only machine-readable, but also executable. Indeed, one could consider having rules and restrictions coded as methods.

Or did you mean TypeSpec (*.tsp)?

I also had a look into ifcx.dev, which basically contains the same information about schemas.

In any case I could not find any full equivalent of IFC4.3ADD2 expressed in TypeWhatever. Since I am an absolute newbie in TS and TSP, inspecting the corresponding files did not bring much enlightenment. I'll have to give it another try.

However I had a closer look at the examples, and more precisely the linear placement of signals. JSON Schema https://ifcx.dev/@standards.buildingsmart.org/ifc/core/ifc@v5a.ifcx provides, inter alia, recognizable fragments from the IfcAlignment and IfcAlignmentSegment definitions.

In the EXPRESS version of IFC4.3 ADD2, the relationship between IfcAlignment and IfcAlignmentSegment is governed by 0 or more IfcRelNests instances, each IfcRelNest instance establishing a one-to-many relationship between the two.

In the ifc@v5a.ifcx schema,

• the containment relationship is direct (IfcAlignment holds an array of references), but
• no restrictions are expressed about what is referred to (array elements could be anything but segments), and
• no multiplicities are stipulated (which entails 0.., where IFC (EXPRESS) stipulates 1.. for each IfcRelNest instance but there can be none, so 0..* is not wrong).

Since ifc@v5a.ifcx also links the objects with their definition in bSDD, I had a look at the IfcAlignment definition there but the relation with IfcAlignmentSegment (via IfcRelNests) is not mentioned. Besides, bSDD does not document IfcRels at all: no wonder, a dictionary not being intended to replace a schema.

So, from this sample only, I am tempted to ask two follow-up questions:

• is there any intention reduce the number of "association classes" / "reified properties" (IfcRel...) in IFC v5 and, if so, is there any general strategy for moving the corresponding information to some kind of annotation? or was the direct association only performed for illustration sake (the main subject being geometry representation)?
• [more to the original point] do you intend to move rules and restrictions to the bSDD layer AND/OR the JSON schema when possible (i.e. simple type and cardinality restrictions)?

Sorry for all possible misreadings and misunderstandings - big subjects and my knowledge is scarce.

[berlotti]

Sorry; yes, of course typespec

[Airy59]

I thought so but again, TypeScript (if not Java) would be an option, probably covering most rule and restriction handling issues. As you aptly put in your blog, IFC is not a format but a scheme (with rules and constraints) hence my appetite for the ways to convey those aspects into one or more computing environment.

[aothms]

Not to disagree, but a couple of complications:

• IFC5 follows more of an Entity-Component(-System) approach than an OOPy way of modelling. So you'd have to consider (unary) constraints within a component (e.g self.length > 0) but also interactions between components: if something has this component, it needs also have that.
• Therefore there is also a less strong focus on classes and encapsulation. The type/class/classification of a node is just like any other component. So the typification of relationships is also per definition more nuanced/complex. (E.g USD has IsA schemas, that govern whether API schemas can be applied, but has no typed relationships).
• IFC5 has composition of layers, opinions. Do you apply schema constraints before or after composition? You probably need both. To (a) validate data delivery requirements (b) to validate eventual model consistency of the composed data.
• IFC5 has children at the exchange specification level, not at a schema level, so you'd need another mechanism for constraining that.
• IFC5 is embedded in other workflows and data procurement standards such as IDS/IDM. The covariance between components on entities, the types of children for parents (IDS has a partOf facet) is likely use-case / domain / region / project -specific and might be better fit for IDS.
• IFC5 will have fewer references because attribute schemas are more atomic and the scene that consists of primitive nodes is more equivalent to e.g IfcObject where a lot of relationships in IFC4 are also near-unconstrained.

The example of the alignment schemas is interesting in the sense that in IFC4 we use generic nesting. So in IFC4 there is also no schema-level constraint that governs the hierarchy Alignment -> Horizontal|Vertical|Cant -> Segment*. Because segments are ordered I have opted for a schema level relationship array, but maybe it's sufficient just define them as children (and implicitly sort them by name or some other order) in that way the schema-level relationship can go away altogether.

Other examples include SpaceBoundaries in hello wall (in IFC4 this is typed from spatial-structure-node to building-element). But I'm not convinced this specificity is needed. It could have also been a generic "topological touching" relationship. And when interpreting data you then specify: I'm interesting in topological-touching relationships between spaces and building elements as those are your space boundaries.

The other example is in domestic hot water, which is a generic connection relationship to model systems. More or less unconstrained in IFC4 and 5.

So yes, I see your point that untyped relationships appear as a step back, but in the overall framework of IFC5 given the reduced significance of types, lack of encapsulation, but also more data-driven use cases where people more flexibly in a project-specific way want to interrogate the data, it might be less of an urgent need then expected when coming from e.g express or owl usecases.

[Airy59]

Thanks for those insights. A few comments (not all related to the original topic though)

"I see your point that untyped relationships appear as a step back": it is not exactly what I meant. "Step back" sounds judgmental. My point is, the EXPRESS schema contains information (constraints) that does not appear to be reflected in the provided samples, so I wondered about the intentions: conveying them into IFC5 (in which form), if at all.

Generally speaking, semantics are (or should be) widely shared, hence the usefulness of typing and subtyping, while constraints are often project-specific, hence the usefulness of expressing them separately, but still formally (I come from a background where high value is placed on data consistency and integrity, linked with legal safety assurance requirements).

Technically, I am not specifically advocating UML+OCL (which I used in the past), let alone a TypeScript implementation (which I have no experience in using), but the formal expression of unary constraints as well as constraints between components could (not: must) make use of methods (in an OOP context) just as it could make use of SHACL shapes or SWRL rules (in an RDF/OWL context) for instance. It just sprang into my mind when I (mis)read "TypeScript".

Concerning IfcAlignment I am a bit surprized when you write:

"in IFC4 there is also no schema-level constraint that governs the hierarchy Alignment -> Horizontal|Vertical|Cant -> Segment*. Because segments are ordered I have opted for a schema level relationship array, but maybe it's sufficient just define them as children (and implicitly sort them by name or some other order) in that way the schema-level relationship can go away altogether."

IFC 4 places multiplicity constraints on the mediated relation Alignment-Alignment segment, and between segments: order is, or rather generates a constraint (which is to keep it, hence to express it formally). I'd advocate against "sort by name" or other non-machine-readable (while certainly machine-processible) conventions, but you could choose others. As an analogy, the order of points in a WKT linestring is preserved by having all points expressed in a single string, so the order of the characters or bytes does the job and any machine will preserve it, unlike alpha sorting. You trade the simplest expression of an order constraint for the burden of doing some string parsing, so to say.

In addition, IFC4.3ADD2 defines Alignment multiplicities that are not reflected in the particular IFC5 sample (fair enough) but could not be reflected (see my earlier post) raising the question of a subtle, but real semantic drift from IFC4 to IFC5: In IFC4, an Alignment could have several segmentations (ordered sets of segments), each segmentation corresponding to a particular instance of IfcRelNests. In IFC5, the current schema won't allow that, if I am not mistaken. The IFC 4 representation would support the use case "at such date, track XXX alignment was composed of these segments. After the works on the tunnel, the alignment of track XXX was changed and is now composed of other segments". With the current IFC 5 scheme, you would have to express things differently, maybe assigning two different alignments entities to track XXX over different, non overlapping time intervals, which leads to the next issue (expression of time-dependence).

The question about "when does a change in an entity result in a new entity" is always open but the reason for my questioning is that the IFC 5 alignment sample seemed to make a silent decision here, which is to depart from IFC4 by suppressing IfcRelNests and the possibly attached info. I am not saying "wrong" but I am asking "why", all the more since IfcRels are a frequent feature of IFC in its EXPRESS version.

Maybe those Alignment-related questions could be moved to a specific issue. Maybe the IfcRel question (which is far more general) could become another one but I'd like you to (re)formulate it because your perspective is obviously wider and deeper.

[aothms]

Thanks for the detailed thoughts. I think most of this can be concluded by agreeing that there is value in constraints, both for verification and documentation. IFC5 is a in a little bit of a different position because it doesn't inherit a rich constraints toolbox such as express in the past. Which is good and bad; (sometimes even imperative) rules aren't always the most suitable modelling mechanism, I think they were sometimes misused, but in many other cases they documented intent rather carefully, even if actually implementing them has only happened in the last couple of years or so in the majority of BIM toolboxes (RDF.bg, ifcopenshell, ...). One way or another they will make it to IFC5 I'm sure, just maybe more bottom up, for concrete needs.

I do want to comment on:

In IFC4, an Alignment could have several segmentations (ordered sets of segments), each segmentation corresponding to a particular instance of IfcRelNests [to model situations as] at such date, track XXX alignment was composed of these segments. After the works on the tunnel, the alignment of track XXX was changed and is now composed of other segments

Because I see this as the risk of IFC's data model. I would say that there is not a lot of evidence that supports your way you choosing to interpret multiple nesting relationships as "variants". The behaviour among viewers will likely be that they fold all nested objects into one set of children. While you could annotate nesting relationships with distinct ownerhistories to provide a relationship to time, that's not actually what ownerhistory signifies, it tells us when it was modelled, not document real-world phasing. Maybe you had other mechanisms in mind (property sets cannot be associated to relationships). I'm not saying your interpretation is wrong per se, just that I don't see if as the only interpretation and then the risk of misinterpretation is huge, while we all think we're working with a semantic computer interpretable, somewhat formal standard.

This I think is one of the major accomplishments of IFC5, reduce indirections that some see as powerful semantic constructs, but others overlook and just result in interpretation discrepancies.

The other power comes from the fact that we have something in IFC5 to model variants, not on the level of schema, but on the level of composition mechanisms. You can organise your model in such a way that different layers represent how alignment geometry has been developed over time. I can understand that people might be uncomfortable with modelling that outside of the schema, but of course within these layers the provenance, phasing and timing can be modelled.

[Airy59]

To sum up the discussion so far, adding some more tentative analysis:

Expressiveness, compared (EXPRESS vs. TypeSpec and JSON schema)

• EXPRESS has rich expressiveness when it comes to rules or constraints on data

• The EXPRESS version of IFC4.3 makes extensive use of this expressiveness; e.g. in IFC4.3.2.0 I found:

  • 436 TYPE, 876 ENTITY, 2 RULE declarations, total 1314, among which
  • 511 WHERE expressions were found.

• the contents of the WHERE expressions often have an equivalent in TypeSpec or JSON schema; examples are:

  • enumerations
  • numeric ranges
  • existence or non-existence of attributes or references
  • boolean expressions
  • types of referred entities (objects)

• however some EXPRESS constructs do not seem to have equivalents:

  • INVERSE attributes (85 occurrences)
  • UNIQUE constraints (16 occurrences) except within an array
  • DERIVEd attributes (47 occurrences)
  • WHERE clauses referencing other entities and/or containing fancy queries: no precise stats, but we found 122 occurrences of QUERY, of which we quote one example:

ENTITY IfcAdvancedBrep
 SUPERTYPE OF (ONEOF
	(IfcAdvancedBrepWithVoids))
 SUBTYPE OF (IfcManifoldSolidBrep);
 WHERE
	HasAdvancedFaces : SIZEOF(QUERY(Afs <* SELF\IfcManifoldSolidBrep.Outer.CfsFaces |
  (NOT ('IFC4X3_ADD2.IFCADVANCEDFACE' IN TYPEOF(Afs)))
)) = 0;
END_ENTITY;

Status: usage

• EXPRESS rules and constraints, as currently provided in IFC, do not seem to be exploited universally nor systematically (to which extent needs to be further researched).

Needs

• constraints may be general or project-dependent, suggesting they be expressed accordingly (with the versioned standard, or separately with project extensions)

Outlook

1. Many constraints currently provided in EXPRESS can also be transposed in TypeSpec and/or JSON schema.
2. For the remaining constraints, typical solutions need to be worked out.

In any case but especially for case 2., the underlying questions are:

• what constraints should be kept in the standard (IFC) as mandatory or informative, in the light of current and envisaged usages? how much continuity with IFC4.3 shall be sought?
• how to ensure that project-specific constraints (more restrictive, or possibly relaxed?) can be expressed and exchanged in a manageable way?

[aothms]

• INVERSE attributes (85 occurrences)

• UNIQUE constraints (16 occurrences) except within an array

• DERIVEd attributes (47 occurrences)

• WHERE clauses referencing other entities and/or containing fancy queries: no precise stats, but we found 122 occurrences of QUERY, of which we quote one example:

The where rules have been a discussion for over 10y in our community, some want more, some want less. There have been talks about many rule languages, incl. shacl and ocl, but one issue is that the rules are very multi-faceted and come express lack of generics (e.g CorrectTypeAssigned to check for the correct coupling between occurrence and type objects) and other modelling decisions (e.g CorrectPredefinedType to check the validity of the ObjectType+PredefinedType object because they didn't make it a SELECT(enum, string) but rather two separate attributes). Other rules are in fact unions in disguise (I think you mentioned that) such as IfcPolygonalBoundedHalfSpace.PolygonalBoundary. And other rules are nice in theory, but less in practice because of the fact that express does not prescribe a width of the numeric types and rules aren't implemented with a tolerance (IfcExtrudedAreaSolid.ValidExtrusionDirection comparing to <> 0.0) so that the intent is in fact very useful, but in importing applications another check still needs to be performed with tolerance and with a fixed numeric precision.

I think an detailed inventorisation of the rules we have in ifc4.x beyond just numbers, but in relation to other rule languages, but also in relation to other modelling constructs (unions, generics, etc.) would be very valuable, maybe not in the short term for IFC5, but maybe more in an academic setting. Happy to collaborate on this.

[Airy59]

Indeed, significant work ahead, and not 1st priority. The underlying concern is, whether (in a transition phase IFC5 / IFC4) IFC5-conformant data would risk breaking IFC4 constraints or rules and create actual difficulties in data exchange. I am in no position to evaluate the risk. If you think it is low, you may want to close the present issue (we are at alpha stage after all). Anyway thanks for the insight you provided.

Note: you mention the troubles with numeric types and tolerances. This is a wholly different subject, namely the modeling of information in engineering terms. IFC is ahead of many other data schemas or models, in the sense that Uncertainty and Tolerance are explicit concepts embodied by PSets. I would not expect IFC5 to try and stipulate about bits and bytes, but rather encourage good engineering practice, i.e. not basing equality on haphazard bitwise coincidence. Even if the byte count is regulated by some standard rules, the bits usually come from some sensors or measurements and can nowhere be considered "the truth", and equality in engineering terms is not the same as mathematical equality. This is where Tolerance and Uncertainty PSets should see more usage than (presumably) now, esp. when BIM data increasingly get used in operations. IFC5 could and should facilitate that.