Hi @alex4omnicon, welcome to the Forum!
You could start with reviewing some of the descriptions on the technical website: https://technical.buildingsmart.org/. You can also look at an article recently written for UpFront eZine: https://www.upfrontezine.com/2020/06/upf-1058.html. There may be a lot of info to unpack there, but I think they give good layman explanations of the very things you have question about.
They aren’t all “formats”, but I can see how the acronym soup can be confusing. Simply put, you could look at it this way:
IFC is the schema to describe the built environment in an open, software-agnostic, standardized way. It is not a file format itself, but it is a description/specification that is formatted in a particular way, with the ability to have multiple file formats for actual usage.
An IDM is documentation of one or more processes that rely on data exchange. The IDM specifies the process(es) and the data exchange requirements. It is a precursor, or source, of data exchange requirements that will be translated into an MVD.
An MVD is a specification for a subset of the overall IFC schema, used for a specific data exchange. Ideally, it uses the same form and format as the source IFC schema to describe the data. But, it can also contain additional specific data requirements, like custom properties, or specific values for certain data fields. There is an mvdXML file format that has been recently developed for IFC4 and used to capture an MVD in a “machine-readable” way.
COBie is a data exchange specification like the IFC schema, but also has a corresponding IFC MVD. It also has an IDM describing why the data is important and how it applies to the owner/operator’s business case. In this case, COBie is focused on the data needed to be exchanged from the design and construction process to the owner/operator for facility management purposes.
An IFC file can be formatted in a couple of different ways. The primary one is a STEP Physical File (IFC-SPF), most commonly seen as a *.ifc file. It can also be formatted as an XML file, *.ifcxml, with the same information as the SPF. An IFCZIP file can contain either an SPF or XML format of the model, as well as supplemental files (e.g. images, PDFs, CSV, etc.). Output using any format really depends on the receiving application and its preferred file type.
IfcOWL is another way of accessing information IFC-based model data and linking it with other external data that may not be explicitly described in the IFC schema. It is a commonly used semantic web methodology. There are some applications that have been developed to exploit this method, but it is not a “common” consumer use. Other methods and formats currently being researched and pursued include JSON and HDF5 based versions of IFC-based exchanges and files.
I hope this helps. If you have any more questions, please ask!
