hi,
do i get it right that the ids goal is to replace the oir-air-pir-eir-bep-pack in the future?
is the both-way interactive ids connection to the information model the intended outcome, self executing as the smart contracts?
thanks,
rob
Where would you get that assumption? These are all process-related concepts from ISO 19650 and IDS is a technical format to specify and exchange property requirements.
OIR-PIR-EIR-AIR are information requirements in general - they may not necessarily relate to the IFC scheme and they may even be plain language.
BEP is also defined in ISO 19650 and it is a document used to describe the processes the delivery team will adopt in an appointment.
E.g., in your IR you express that you need to perform a sustainability assessment during the design phase and that you require an as-built model at handover.
E.g., in your BEP you can clarify the information delivery strategy and information management functions of the delivery team, which software the delivery team will use and indicate the different task teams and their responsibilities, etc…
IDS is a straightforward and technical way to express property requirements for IFC files. The way it is defined, it assumes you use the IFC scheme.
E.g., in IDS you express that all objects of class “IfcWall” need to have a particular property “X” in property set “Y”.
When IFC analysis software tools support IDS, they could check a submitted IFC file against this information delivery specification (IDS).
stefan,
i’ve already got some information from leon de berlo.
the thing is the simplification of the information requirements. when i have to manually update a bunch of documents during the investment process it’s not an improvement, but a burden.
leon has assured me that the ids would possibly automate everything that can be automated, and i can live with it.
as for now, the information requirements are only for the managers who actually don’t create value for a customer. the real value happens on the gemba (the real place, meaning the designers’ computers and the building site) and the workers don’t profit from the information exchange.
the whole bunch (oir/air/pir, and bep) is not helping, but quite the contrary, making managers busy with things that are non-value-added work.
If it is not helping, then the “appointing party” (client) has not stated their requirements sufficiently. It’s all about focusing on what you need. What a client or end user needs from a building may be entirely different than what the architect or the contrator need. Design and construction are only a subset of the lifecycle of a building, let’s not forget that.
So that is why you have a cascade of requirements: from the client (stated from OIR-AIR-PIR into EIR) and then cascaded throughout the whole chain: added requirements from architect, engineer, contractor, manufacturer… And if using IFC, IDS can be a standard format to express property requirements and to feed checking systems to verify the information deliverables against those requirements.
But a property requirement is but a formal way to express and formulate requirements. A client does not request the “FireRating” property to be added into “PSet_WallCommon” for an “IfcWall”, but rather requires a building that adheres to local fire regulations. And the local authorities may use the IFC file to pick up the FireRating as input to their evaluation.
That to me is the value of IDS: the part where the different information requirements (as result from following the whole process before) can be translated into specific and verifiable pieces of information.
so i don’t see any discrepancy in our attitudes 
my point is to collect all information requirements in one document (it can be done, and it’d be easier to update it during the process, at best atomatically), and to fulfill those requirements in one document, too.
i am a fan of lean and simplicity, and my next question would be: ‘can it be both served with one document at all’?
so the last question is obvious: ‘why not?’