IFC Express Schema: Self In vs Enumeration

richardwhitfield

I was wondering if anyone would be able to shed some light on the IFC schema as described in the Express format?
In the Express definition for IFC (in my instance I am currently looking at version 4.0.2.1) there are quite a number of elements which use the WHERE rules with SELF IN followed by a number of options. For example, in the below code the IfcTextAlignment type seems to be 'restricted' to left, right, center or justify.

TYPE IfcTextAlignment = STRING;
WHERE
WR1 : SELF IN ['left', 'right', 'center', 'justify'];
END_TYPE;

If this is the case then why is this not an ENUMERATION?
The various presentations of the schema are very unequal...it seems like only the Express format represents the totality of the IFC definition. Unfortunately this is the least supported in terms of parsing these options given that it is somewhat domain specific here.
Any help would be gratefully received. Cheers, Rich

Moult

Objectively, it is indeed true that it seems equivalent to an enumeration. My guess is that this is one of the necessary evils of an ISO standard - in that you don't set all the rules yourself - you play nice with as many other international standards as possible.

For example, IfcTextAlignment states:

NOTE Definition according to Cascading Style Sheets, level 1
The actual justification algorithm used is user agent and human language dependent. If 'justify' is not supported, the user agent will supply a replacement. Typically, this will be 'left' for western languages.

NOTE Type adopted from text-align defined in CSS-1.

... as expected, it is used in IfcTextStyleTextModel which as it says:

Definition according to W3C for Cascading Style Sheets:
The properties defined in the text model affect the visual presentation of characters, spaces, words, and paragraphs.

NOTE Corresponding CSS1 definitions are Text properties (word-spacing, letter-spacing, text-decoration, vertical-align, text-transform, text-align, text-indent, line-height).

You will find other scenarios where IFC opts to adopt rather than reinvent. Like IfcBoxAlignment used in IfcTextLiteralWithExtent which has a similar WHERE RULE which states:

NOTE Entity adapted from text_literal_with_extent defined in ISO10303-46

Quite a lot of the annotative (or paperspace) elements come from other standards.

As for EXPRESS, I believe IFC is moving to UML, but this is a question perhaps for @berlotti and @aothms. I would however find it surprising if you need to directly parse EXPRESS, as there are already established open source IFC libraries for most programming languages, like C++, Python, C#, Java, Perl, Javascript...

berlotti

The main development of IFC is now (IFC 4.3.x) indeed done in UML. This is for maintainance and development. See the work here: https://github.com/buildingSMART/IFC4.3.x-development/tree/master/schemas (kudos to @aothms ) There will always be an express schema available that is generated from the UML. Just like pot files for translations, a json overview of the entities and properties, eventually an XSD again as well, etc... See the output that is generated here: https://github.com/buildingSMART/IFC4.3.x-output/
We are slowly moving towards a more 'crowdsourced' way of developing IFC. The weird exceptions in the schema are not always known (due to historic reasons) and with the GitHub tools we are opening to the community for help and suggestions of change.
The documentation is also on GitHub https://github.com/buildingSMART/IFC4.3.x-development/tree/master/docs equally open for help and improvement from the community. Welcome!

richardwhitfield

Thanks @Moult & @berlotti , the ISO standard(s) would be very useful for me but unfortunately my little startup budget doesn't stretch this far yet! This makes sense to me and validates some 'assumptions' that I had around some elements.

I have looked into some of the existing OSS implementations but I haven't yet found one which both meets my needs and is open to input. I have some fairly specific needs in trying to make IFC work in a cloud based environment (one which doesn't involve the exchange of whole STEP files) but I will make my base structure open source also.

Had pretty good luck with a number of options so far ...have basic types extracted for the RDF, XSD using existing parsers and have used ANTLR4 to parse the EXPRESS format. I do have this working also but it's much less elegant so I was having a final look over the other formats first.

Thanks for the pointer on UML...I have done some further digging and seen some of the aspirations for IFC which seem to echo some of what I hope to be tackling so if I find that there is any way I can contribute then I will.

Also thank you both for such prompt responses, I didn't know if I would even get an answer to this query so this has really made my day! Also good to see that the MD supports code as well, didn't see that before I put up my post!

Moult

Cheers! @richardwhitfield by the way I'd love to know why / where you think FOSS implementations like IfcOpenShell, XBim, IFC.JS, File::IFC, etc fall short. I was under the impression that they offer some of the most advanced, if not the most advanced IFC related features available that simply don't exist elsewhere (high level API, transactions, WASM, 4D/5D, drawings, ownership tracking, multiple serialisations, the list goes on), and all are very open to input.

There is nothing particularly special about a cloud based environment, or the lack of STEP serialisation in your request. For example, IfcOpenShell supports XML, JSON, and some experimental others, and it's quite trivial to connect it to your own bespoke API behaviour. I am personally using IfcOpenShell is a few internal clouds (a fancy way of saying either web app or REST API) and I have no doubt others are too and STEP is definitely not a requirement.

If you're worried about licensing, LGPL allows commercial use - you would be joining numerous others who already use IfcOpenShell commercially. Similar commercial usage is possible for XBim / IFC.JS.

Oh, and a P.S you might find https://wiki.osarch.org/index.php?title=Free_software_libraries_for_AEC_software_development interesting if you're building things :)

aothms

As @Moult said these are mostly derived from other standards. I agree that when you look at such a definition in isolation then it's an enumeration in disguise. But express is massively complex, it could be there is, for example, a function that expects the data type to be interpreted as a string, maybe there is a something in part 46 that does something with substring, case, concatenation? Really not sure, but it could be.

richardwhitfield

Hi @Moult , I don't believe that these OSS implementations do fall short, as you suggest there are many very capable libraries out there. My experience in the "open to input" portion however was not as I had hoped.

It's also not the STEP format in particular which is giving me any issues, as you mention this is just one option for serialisation of a model. I am looking at non-model based persistance options so the ability to extend the libraries is important to me and I think I will end up opting for an event sourcing approach to persistence which doesn't fit that neatly with the way that some of the libraries are conceived.

Re the licensing I have been doing quite a bit of reading around this also! I am very impressed with the permissiveness of the libraries that you mentioned which is one reason why I would also be open sourcing the base models and operations if I end up going down this route. Thanks for the link to the libraries, this is a wealth of information.

@aothms thanks for the response also. It seems like the Express format is really the only way to go for the current 'official' IFC implementations if I want to capture everything.

Thanks again everyone for the responses!

aothms

@richardwhitfield it depends on the time frame also. As @berlotti mentioned we're quite far with the UML representation actually being the master copy. In many ways it will be richer than the Express currently is, because things currently outside of the Express schema, that are very significant to usage are modelled in UML. Such as IfcPropertySet definitions, their relationships to entities, but also the pairs of valid IfcObject IfcObjectType relationships. As an example: The relationship between IfcWall IfcWallType and PSet_WallCommon is available directly in UML. On the other hand it will be quite visible that we were once / are an Express-based standard, so things like express functions and where rules will be opaque definitions in UML for the foreseeable future.

richardwhitfield

Thanks @aothms , that's a really good point. Could I ask one more question on the UML implementation? Is this intended to be available for the retrospective versions of IFC as well?

aothms

That's more of a question for @berlotti

I don't think it has been discussed. The reason for adopting UML is foremost internally to have a reliable schema authoring platform. Therefore, back porting that to earlier schemas doesn't make a lot of sense, not officially at least.

On the other hand, since the IFC4.3 UML was conceived programmatically it's also not unthinkable that buildingSMART facilitates something like that?

berlotti

The main reason to adopt UML is to broaden the group of potential collaborators on the development. IFC 4.3.x will continue to be developed for a while. We expect updates based on practical use, and the Tunnel domain will be added as well (might be 4.4).
Since the previous versions of IFC are not developed with the same intensity, the effort of setting up a UML based deployment system is probably not worth it. Voluntary help on that would make it possible of course (hint.... ;-) ).