This topic is for discussion of long-term concepts (around 10 years to market penetration) that are related to “Federated Decentralised CDE”.
It is primarily addressed to “masterminds” with knowledge in construction AND information technologies to discuss long-term goals and solutions based on current shortcomings, concepts and scientific findings.
Anyway, people without IT background are as well welcome to contribute. Please be aware that discussions within this topic will not solve your short-term challenges in real-life projects.
[Werb2019] Werbrouck, J., Pauwels, P., Beetz, J., & van Berlo, L. (2019). Towards a decentralised common data environment using linked building data and the solid ecosystem. In 36th CIB W78 2019 Conference (pp. 113-123).
Could you please provide a short summary of your thoughts about [Werb2019]?
Where are similarites and where are differences to your conceptions?
I am capable of programming but I am not a typical programmer as I am as business analyst interested in general business process concepts and related information management.
Therefore I would like to discuss the topic on ERM level (Entity Relationship Model) independent from “data formats” like XML, JOSN, RDF / OWL, RDB relationsschema / SQL.
I think that IT concepts are good that align to real-life as far as possible.
Logic Theory provides a good basis for knowledge management.
In real project life we use statements / questions / answer-statements to communicate requirements, feasibilities and solutions between stake-holders.
Therefore I think that logic theories provide a good basis for algorithms to identify and solve contradicitions.
To allow for uncertainty and weak statements the fuzzy logic theory could be engaged.
This would be in line with the current trend towards loose coupling of atomic information parts (e.g. RDF/OWL in semantic web or similar a high degree of normalization like 5 NF in relational databases)
@ReD_CoDE: Thx for the reference to IFC SQLite Project. I will have a close look to that.
In principle I aggree to the statement of @bsbock about “benefits of sql based working” with RDB (relational databases) .
However, it is the purpose of RDB to be very strict and always consistent in an mulit-user environment.
This is mandatory for application fields like financial accounting.
Otherwise, in construction projects we see a lot of imprecise volatile and uncertain statements, especially at project start.
I did my master thesis about “Process Monitoring for Complex Engineering Processes” with BPM methods. I realized that modelling methods that are flexible and allow the consideration of uncertainty and probabilities are needed to cope with real project life. Strict and inflexible modelling methods are far from reality and therefore inadequate.
I will further develop my thoughts and concepts and provide them to the forum as soon as mature results are available.
@ReD_CoDE: Do you have more information on your “whole model-based systems engineering approach”?
GRV & GDT purpose global ready-to-use geometries/topologies and data/information units like LEGOs that we have the ability and flexibility to put them together and build (IDM/MVD approach) our “dynamic” MVDs
Yes, there is unstructered, semi-structured and structured information to be managed (stored, delivered, logged, updated, archived).
I would like to see in the future a significant shift towards structured information. Structured information (e.g. based on ontologies) can be processed by using logical rules. It faciliates automation of colission and contradiction detection as well as the integration of different knowledge domains (like FOWLA approach mentioned above by @ana.roxin).
For better software support and integration we need loosely coupled but well-structured information sources based on simple, consistent axioms and rules. Only very simple “sentences” like RDF tuples are reliably and efficient processable by computers. Computers are stupid machines even though AI industry sells other dreams.
Simplification of requirements towards computer interpretable specifications, standards, law, etc. is a key success factor for federated business integration as a further development of federated decentralized CDEs.
If you look at an IFC file in STEP format, it is in itself an extremely simple and structured format:
a line ID (#123)
a class (IfcWall)
all attributes, in a fixed order, according to a predefined scheme for a particular domain or context
Yet in itself, it is able to express all the concepts and relations from the IFC scheme.
What you cannot do is stream it, as you need to parse the whole document before you are sure your information is complete, even if all you need is a small fragment. Streaming, logging, parsing extremely large files etc… becomes problematic.
‘a significant shift towards structured information’…
that’s what probably all advocate.
but as i read the first part of the iso 19650 norm the notion of the information structuring is not being encouraged enough. the last, 3rd stage of information evolution depicted in the paper still contains ‘unstructured big data’… so where is the clear goal for the future?
the big question: how to organize big data in a structured way? ascii-converted, based on tags?
Yes, IFC file in STEP format is very useful.
It is simple, structured and provides numerous modelling concepts.
From my point of view IFC should be acompanied by concepts for more flexibility and concepts for more standardiziation.
Is this a contradiction?
I see the need for
more flexibility on project instance level (the business-cases, the projcet evolution)
more standardization on project type level (the business-processes, the general use-cases)
Starting with project ideas and project portfolio management an accumulation of typically imprecise statements from different stakeholders evolves over time: Ideas, wishes, dreams, requirements, confirmations, warrants, claims, …
Systematic collection, assessment, tracking and refinement of statements and corresponding deliverables are key success factors for projects. This is related to requirements engineering, verification and validation (e.g. V-model).
An IFC files describing a buidling proposal could be derived from general statements (e.g. based on ontologies) about the buildings general properties (size, budget, base area, general shape, …). Refinement of the proposal can be done by making additional statements.
The other way round general statements (e.g. based on ontologies) about elements could be derived from an IFC file (see “Ifc Web of Data ontology (ifcOWL)” mentioned above by @ana.roxin. This allows for semi-automated consistency checks between IFC file (implementation based on requirements) and the underlying requirements (general statements) based on logical rules.
More standardization on project type level addresses the current drawback that different modelling concepts / representation paradigms are in use for the same use-case.
I am still aware of your objection in
highlighting “More than one way to geometrically describe an object”, “Modifiers”, “Semantic or geometric focus”
Nevertheless I did not give up the hope that more unification based on standardized decision rules could be possible. I will soon address this with a separate discussion topic “the wall”.