It’s around 6 months we have had a lot of discussions around many things, especially IfcDoc and the issues had and still has
… the logic behind the IfcDoc tool makes the IFC schema and the IFC schema development more dependent on its data modeling tool which today has issues and buildingSMART International has started to develop it again based on UML, but in reality, UML will not solve the dependency barrier, likewise. … GitHub - IfcXtreme/IfcXtreme: The next generation of IfcDoc
And I shared the SysML structure, it supports:
Structure (IFC has)
Behavior (IFC doesn’t have)
Requirements (IFC somewhat has)
Parametric (IFC doesn’t have, such a way the SySML provides)
And many things SysML can add to IFC
Also, it not only can revolutionize IFD and IFC, but also can revolutionize IfcDoc and even tools
How are we to know what you have been discussing for the last six months?
Granted, there are known issue with IfcDoc tools (main issue is development stoped - contact Tim Chipman to discuss that if you like), and an alternative that is much better is ISO Schematron (Main developer that comes to my mind is Chris Bogen)…But what does that have to do with this topic?
If anything, to change to your suggestions, add more issues without clarity, e.g. we know how to automatically verify, and semi-automate the validation IFC model view definitions using ISO Schematron - but you have not explained how to do the same with your proposed method…(to verify and validation definitions used here are as per ISO 9001 and utilised in the production of COBie files, etc.)
To verify = is the data in the correct format, e.g. for date and time it must be according to a standard like ISO date and time…this can be done by machines.
To validate = is the information what was required, e.g. is the date correct - which is a human decision.
Please explain how what you speak of is related to the topic at hand, or I will have ignore your postings here on…
EXPRESS can model structure (entities and types), requirements (where rules and global rules), behaviour (functions and procedures). I don’t know what you mean with parametric in this context.
On top of that, EXPRESS is a machine readable format describing these structures, so Express can be used for automatic validation of files, code generation, etc.
But this is going off topic, so I’ll not continue discussing SysML here unless the discussion again moves toward the original topic (modularization). Please start a separate topic if you want to propose SysML and explain what you mean by that.
MVDs finally made progress on this front and we can rely on computers to check compliance of files (a lot of man hours have been saved!).
Why only rely on the schema for requirements? An IfcSpatialElement is a product, an IfcElement is a product. But does it make sense to recommend/mandate geometry on both? Not really. Modularization does not solve such issues. I would agree with all your points.
i would be again at my original question. What is modularization supposed to achieve that the subschemas and MVDs haven’t? Just putting another name tag on concepts does not change the principle of how they are used.
To me it seems there are a lot more pressing matters such as developing the tools to support the methodologies.
The discussion of UML/SysML is already an ongoing discussion as part of the re-architecture of the IFC schema, and moving its authoring and editing using UML/SysML (with GitHub-based source code repositories) and then “exporting” to EXPRESS, XSD, OWL/RDF, etc. for use as needed and preferred. Let’s park that discussion for now.
Since EXPRESS-STEP is NOT the only means of manifesting and using the schema, can the modularity of IFC be reconsidered. I think @nn1, @Moult, and @Helland were onto something.
@sergej While MVDs have been somewhat useful for certification, I think there is now agreement it doesn’t really work well for certifying the full competency of software. It’s fine for a particular MVD and workflow, but often times end users want to know if it is possible to create new MVDs that their software can support. Maybe certification needs to be unit test-based, covering more discrete concepts across a larger scope of a domain. But this also only works of we are also more explicit or restrictive with the schema itself (e.g. which geometric representations are really acceptable/useful for which object classes), while at the same time more flexible (e.g. all files MUST include a BREP geometric representation with any advanced geometry to allow the receiving application to choose).
I think there is no argument that MVDs are the most practical means of exchanging data/information, for now. But if we consider more discrete concept exchange methods based on QLs and JSON-based transfer (e.g. Vectorworks querying Revit for “all steel columns on Level 12”, or “800mm concrete foundation wall” and importing the results), the scope and use of MVDs may evolve… or not… or more limited to specific standardized contractual requirements rather than more fluid modeling and exchange usage.
I still do not see how modularization can help with certification.
@jwouellette In your consideration about MVD, where do you think that the schema has to be more restrictive? This is something easily handled by MVD through concept templates, concept inheritance and concept configuration (RuleIDs). Say IfcElement can have anything from BREP to CSG, but when you look at IfcWall you will only see Axis 2D Geometry, Surface Geometry, Body SweptSolid Geometry and Body Clipping Geometry concept templates left over. If you want to be even more precise, you can configure these at concept level through RuleIDs. That sounds pretty strict to me. Let us not forget, this is checkable. How would you propose to do this at schema level? It is not even possible to be this strict and flexible at once. Are you proposing we change the schema modelling language? Which modelling language supports something like this?
Of course end users want to use MVD to specify their own MVDs (including us at Siemens) but configuring the RV already seems overkill for typical use cases. Wouldnt’t be possible without MVD. We can specify which kind of geometry we want for e.g. walls. If authoring software would be able to read .mvdxml I could just submit my requirements and get exactly what I want. Instead of pushing information I would be pulling (@stefan.markic why did you not talk about this at ISG? ).
The discussion to me (as I have now asked a few times over) should answer the question: “What is modularization supposed to achieve?” Better certification? If this is the answer, I do not see how. Would you just have Select Types for your datatypes? It would also mean you have to abandon inheritance. Further down, making the schema more strict, you would run into problems on national level not even talking about enterprise and project level yet.
It seems that until you decide which modeling language is good for IFC, something new comes to the industry
Ah! I forgot, IFC is an open standard
@sergej Are you aware of IDM Toolkit projects?
You purpose the idea ISO19650 and also IDM Toolkit suggest, my trick is that “I will put IDM Toolkit and IfcDoc inside the software” but “based on Model-based approach”
I don’t think modularization really has anything to do with certification explicitly, rather it is more about software implementation, in general, and the scope of an ever growing schema that is supported by a growing number of software platforms for a growing number of stakeholders, workflows, and domains;
By further considering modularization, maybe we can determine the variation in scope of IFC support for tools to fit within the larger context without requiring support for every concept of every domain in every tool. Yes, the use of MVDs is still needed for many kinds of data exchanges, but that is beside the point;
As I, and many others, have recognized and stated before, there is a certain modular structure to the schema today. But, is it it the right one? @ReD_CoDE brings up a rather radical “throw the baby out with the bath water” proposal, which may be suitable only further down the road. Today, we have to deal with a large amount of work being done in the Infrastructure domain that is predicated on legacy methodology. Any near-term proposals may be less disruptive, but might foreshadow a more radical looking future.
I thus return to my previous comment about what Léon’s proposal may look like (@ReD_CoDE there is no need to reiterate your view, yet again). He’s thrown a serious idea out there looking for serious consideration about a possible path forward.
Or are there restrictions that need to be removed in order to enable better modulization and compatibility?
Maybe it helps to start by comparing Léon’s @berlotti diagram with the IFC diagram @sergej posted and further considering the implications. Again, there have been hints of such ideas, but being less dismissive of the proposal would be more helpful.
A) I have not said that MVDs aren’t important, but MVDs are about data exchange, not the schema itself. They are one tool of moving data in an IFC-based system, but may not be the ONLY way (just considering the use of IfcOWL, JSON, and QLs).
B) Current IFC implementations are generally pretty limited in their MVD EXPORT support (and some limited in their IMPORT support). Most are limited to the official bSI IFC2x3 CV (and a couple IFC4 RV). In doing so, some applications have tailored their solutions to these “official” MVDs and then lack the flexibility to support others, especially those that may have very different ERs. Some tools have limited their capability in supporting some of the schema Resources, particularly geometric representation. This means extra work to convert advanced geometries, risking error or failure.
C) Also, not every MVD in the future will be a subset of the RV or CV or DTV. Some applications give users an option to “customize” their IFC exports from within, without developing an MVD externally. Such results are often unpredictable and unsatisfactory because not all users are aware of all the options they have and should, or should not, be using. Flexibility also enables less confidence in the users’ experience when results don’t meet expectations. We can’t expect bSI to create all MVDs for every workflow… it has neither the resources of bandwidth to do so, currently. Not every end user can be an IFC expert, nor should they be. Instead, the thinking is how can we make results more predictable and foolproof?
D) In my example, the “unit tests” could be “micro MVDs” or SEMs (aka Semantic Exchange Modules… thanks to Chuck Eastman), that are explicitly limited in scope to a single, testable concept, which can then be aggregated to form larger MVDs. Users could create valid MVDs based on their on-the-fly configuration of SEMs within software, hopefully with a UI consistent between platforms, as well as performance. Current checking tools should still be able to accommodate this. It is not a technical issue so much as a process one.
Enough (if not too much) said for now to digest. The broader MVD discussion should be taken to another topic.
@jwouellette Let me share my view when I saw @berlotti’s presentation in China when shared it through LinkedIn:
As I see you mainly try to find a good structure for Product Data Template (PDT) and the modularity Leon suggests is the modularity we want too. Before this Bill East for COBie projects tried to build something efficient for Product Templates but I don’t think those templates as html templates were good enough
What Leon suggests is good, but needs “FEDERATED” files and even schemas, which current STEP/EXPRESS doesn’t support
If it happens even we can have two separate schemas one for bSDD (IFD) and one for IFC and drop all repeated parts in IFC like IfcProducts and instead integrate both schemas to work separately and together
And have federated/integrated schema parts as modular parts that have their own flexibility as modules but work with other parts as a whole
Then bSI can examine each module separately and add in certificate each software supports which modules
Again, can you be specific…“good enough” for WHAT?
The templates design for the Specifiers Information Exchange (SPie) Project were design for very specific and verifiable purposes. Issue here, in general, was the support of manufactures is where this fell short. This will be the same case no matter the product template method.
(FYI: These templates did exactly what they were designed for, so please be careful misinforming the public with your opinions! which still to date you have not baked up with fact … so please answer the question…“good enough” for WHAT?)
(In many forums you mention this, but never explain the WHAT you refer to. You cannot say things like “good enough” to a scientific community, especially if you want them to listen to you and take you seriously. While some may be intrigued by your ideas, you are not helping anyone by speaking this way, including yourself. When scientist want their ideas APPLIED, we share examples to build upon…can you do this in this regard?)
So, what are the templates you refer to EXACTLY for (explicitly), and how can one test them? (Do you have an example that works to share?)
Industry practitioners cannot use any type of template that is not explicitly defined, because it cannot be tested. Hence, BIM Objects for 3rd parties all over the globe that are most useless because they have not been tested for specific use cases, e.g. tied in to any IDM etc. Many are not even good enough for construction drawings which is the initial primary purpose, much less suffice for accurate information exchange.
How does what you have realised about Leon’s presentation, solve any of the above?
I clearly know about all projects Bill East leads, and I don’t see any future for them, even if NIBS and bSI support them
I don’t say your issues, because I work on those issues
I think this is off-topic and as I said wait until the industry judges on solutions
Even bSI supports some projects that personally I don’t see any future for them, but I’ve waited at its right time show why those projects were not “GOOD ENOUGH”
We may believe you if you share concrete examples in which your opinions are based upon. And it is not off topi because you brought this up as something you attained when analyzing Léon s presentation, was it not?
I think it is good you bring up state if the art which should be addressed in this topic. But, you must be factual versus opinionated.
).
