The Project’s Technical Team has drafted the initial specification for mapping this MVD’s requirements to spreadsheet form. Want to provide feedback to the team about this report? Provide your comments below (with section and page numbers please!)
Thanks for the post Bill! 
Looking forward to hear what folks have to say.
To ensure that software vendors can implement this conversion accurately, would it be possible for you to:
- Provide the tables in a computer interpretable format? (i.e. a JSON list of allowed IfcTypeObjects, excluded psets, etc)
- Provide a single IFC sample file to use as a test case
- Provide a single example conversion to use as a test case
I see that this differs quite a bit from the previous COBie IFC->SpreadsheetML mappings. I’d be happy to help build an open source converter to test out this specification in practice. If there is a test case and a computer interpretable format this can be done much faster
Oh, and a very minor point … it seems to always have been called “Pset”, not “PSet”. Can we standardise this capitalisation?
1 Like
Can I clarify the naming of this MVD in relationship to the “COBie” brand? Many clients ask for “COBie” simply because COBie has almost turned into a buzzword. This can lead to confusion.
My current interpertation based on the document is that this MVD is for FM Handover only, i.e. the information transfer happening at construction handover. Then, there is another separate MVD (perhaps called COBie - as that is what is listed on the buildingSMART MVD database?) which is for operational information exchange during facility management itself. I don’t know where the draft for this is. Can you please confirm / correct me if I’m wrong?
Hi @Moult,
This proposal is a revision of the original bSI 2009 Basic FM Handover MVD for IFC2x3. It is using “https://www.buildingsmart.org/fm-handover-equipment-maintenance-project-a-lessons-learned-and-requirements-report-has-been-developed-by-the-project-leadership-team/” as the basis for the revision/update because it is a previous bSI work.
COBie is a US NIBS-specific FM data handover specification and considered “proprietary” (by NIBS), even though it is a derivative of the Basic FM Handover MVD. On an ad hoc basis, other countries have adopted either the original bSI or NIBS-COBie specifications since their publishing, some even making further customizations for their uses. However, this has led to further confusion in implementation and support. All of this is explained in the referenced “Lessons Learned” draft documentation.
This proposal re-asserts the “international standard” provenance of the data exchange, but narrows the scope of delivery of one particular MVD to “Equipment Maintenance” data handover, and also sets up a framework for other FM data exchanges based on the same core principles and IFC mapping. These other exchanges, as specified by the documentation of their uses cases in future projects, will be tackled by other bSI community members, using the same logic. Also, the proposed framework will still allow customizations for unique national requirements/use cases, but still be compatible with the “FM Handover” core logic and thus still truly interoperable.
2 Likes
@Moult, As noted in the original 2007 specification, the 2009 bSI approved MVD, and the IDM documentation of business processes, the requirement is a life-cycle set of information exchanges defining when each party to a project contributes the information that creates a real-time as-built project record.
The mistake most implementers (including countries previously implementing local specifications) is to think of these requirements as something that simply is done at the end of a project and then dumped off on the facility manager. For a complete review of the lessons learned resulting from incorrect implementation of the original intent of the MVD see our separate thread related to lessons learned.
1 Like
@Moult, indeed as planned, is to of-course provide sample files for testing. However, we are not there yet. There are already ISO 10303-21 STEP Physical File to JSON converters you can use too. I’m sure we can convert the IfcEntityType Inclusions list too.
In regards to the JSON part of things, we will need to coordinate with the IfcJSON project currently underway in the Technical Room. They are working in conjunction with the IFC4.3 Validation and Deployment projects and will wrap up their work on what the ‘official’ JSON implementation will look like once the schema is finalized.
2 Likes
Thanks @jwouellette that clears it up. I will continue to promote usage outside the U.S of these lifecycle-based FM Handover exchanges instead of “hey, we want COBie”.
@DrShawnOKeeffe / @jwouellette I think there was a misunderstanding about the JSON. I’m not after an IfcJSON. JSON was simply given as an example - I’m after some form of computer parsable format of the spec. In the same way that IFC can be provided as an EXPRESS file, it would be good if various appendices and tables of these FM-related MVDs could also be provided as a file (which may be JSON, CSV, XML, or any other parsable common format). To help explain, the spreadsheet mappings are given as a series of PDF tables. This makes it very error prone for implementors. We will likely may mistakes if we cannot parse it unambiguously. There are many notes which need to be interpreted. Similarly for the allowed Ifc Type object tables (figure 34 onwards)
Even right now, these tables are ambiguous to a computer, and even as a human I struggle to interpret it. In Figure 8, what does “IfcOwnerHistory” mean for AuthorOrganizationName? It is not an attribute, so how does the lookup work? Similarly, some are IFC entity attributes, and others are psets (e.g. FMH_PSetCompany.URL) - and what is that pset meant to be assigned to? It can’t be assigned to the IfcOrganization. Another example, still in Figure 8, is “IfcOrganization.GlobalID”. This attribute does not exist as IfcOrganization is not rooted.
Can you please help explain? If these are indeed errors in the document, I would be more than happy to spend time with you to create sample files, computer-interpretable specs, as well as freely available conversion tools to make sure the industry gets this right. I am very keen to see people being able to confidently author these MVDs in the future, and not just treat handovers as a manually butchered spreadsheet that have inconsistent or no correlation to the IFC schema.
Cheers
@Moult I’m going to leave the answers to your questions to @DrShawnOKeeffe and @bill.east, but can say that these are some of the things best suited for the Technical Team of the proposed project to tackle.
@Moult Well some things in your message are very clear (1) you are interested enough to engage the team in some detail - this means you see the need and want this to work and (2) you are unaware of the role of the underlying IFC Schema and SPFF files in the one of the pathways for creation of the data. Now that we have your attention and you have some interest in the outcome of the project, I recommend you and @jwouellette have a conversation about direct project participation and sponsorship. Sponsorship is required to move the conversation from a web post to a standard.
@Moult @jwouellette @DrShawnOKeeffe Please note that moving clients to the new FM Handover Equipment Maintenance MVD is premature. We are starting to outline the project and gather those interested in making it work. 12 months after officially starting the project (which we have not done yet) will result in a Candidate bSI Standard. 2-3 years after that will be required until large software vendors can add the resources they need to implement, test, and deploy the new standard. So, what can be said is… We want to start a project to improve on the 2009 bSI Basic FM Handover MVD. Participation and sponsorship of the project is vital if all relevant points of view are to be heard and incorporated.
1 Like
@bill.east I understand moving clients to the new FM Handover MVDs are immature. I was more interested in the correct terminology in the future.
Yes, I am indeed interested enough to engage the team. However, I’m not sure what you mean by “unaware of the role of the underlying IFC Schema and SPFF files”? My questions were specifically about using the IFC Schema via the SPF as the main data source, then using the SPF mapping as per your specification. To clarify, in my previous message, when I say “lookup”, I’m referring to looking up via IFC schema relationships, nothing to do with spreadsheets.
Where is the best place to get technical answers from my questions? Where can I find the technical team? I’ve love to participate further, (ping @jwouellette as you’ve asked) . I’m not sure if I’m misreading your message but are you asking me for money in order to participate? I’d gladly volunteer time and resources, but I’m looking at this from a technical perspective, not an investor 
2 Likes
Hi Bill, I don’t proclaim to be a COBie expert but glad to be able to provide comment!
15.7 pg27 para 3 - Agree with this being a rule with the introduction of parent zone. Could the picklist values for Zone category be expanded? I have worked on multi-use projects which could use extra categories e.g. for retail areas & risers.
15.09 pg 28 para 3 - Clarification, does this mean non maintainable IfcTypeObjects won’t be exported into the MVD? Or won’t have the available properties?
15.10 pg 28 para 4 - What would be the value of linking model elements such as doors to systems? I have done it before but I they haven’t been used. Are systems more useful to the end user for elements which are physically fed like an HVAC system?
Figure 14 pg 38 (Space Worksheet) - Could Space.Name take from IfcSpace.Number and Space.Description take from IfcSpace.Name. This is how I often see it delivered and it commonly aligns to other project materials being created such as general arrangements.
-typo on Order F “fcSpace.Description”
Thank you.
More detailed review:
-
Page 16:
For example, the Imperial linear measure “six feet, two inches” (6’ -2”) shall not be allowed. The transformed value of “6.5” shall be used instead.
How did you get 6.5?
-
Page 20: 13.9 Guid data type. The weak randomness has already been brought up quite a few times on this forum. There are standards in place for this. If this were confirmed, then you would no longer need to specify it in your document: see Specify a UUID version for GlobalIds · Issue #49 · buildingSMART/NextGen-IFC · GitHub
Also important is specifying the encoding of the GUID. I have seen COBie deliverables which sometimes specify the IFC GlobalId in its 22 character base64 representation, and others in the expanded representation. I believe this should be specified, as well as clarified how it should deal with upwards compatibility to IFC5 (see Use common base16 encoded GlobalIds instead of bespoke base64 · Issue #8 · buildingSMART/NextGen-IFC · GitHub).
-
Page 24: 15.2 Header and Page 33: Figure 7. Please specify MvdName and MvdVersion. I have seen many variations of MVD names and versions in SPF headers and no official list. If you clarify it we can avoid this problem. The “SoftwareName” field does not have a clear mapping it seems. Do you mean preprocessor version, originating system, or both?
-
Page 25: 15.3 Organisation.
The worksheet mapping between the FM Handover - Equipment Maintenance MVD and this worksheet shall conform to the information provided in Figure 4 MVD Mapping to Company Worksheet, page 33.
Figure and page references seem to be incorrect? I assume it should be Figure 8, “MVD Mapping to Organisation”. The reference to figure 5 also seems incorrect. All references to “Company” should also probably be changed to “Organisation”, if I understand it correctly.
The MVD mapping in Figure 8 does not make sense to me. Here is an itemised list.
- A - Name - IfcOrganisation.Label. The IfcOrganisation class does not have a Label attribute. Perhaps you mean IfcOrganisation.Name? If so, I would also perhaps recommend IfcOrganisation.Identification instead.
- B - AuthorOrganisationName - IfcOwnerHistory. Does not make sense. An IfcOrganisation is not a rooted element, and therefore cannot have an ownership history assigned to it.
- C - AuthorDate - IfcOwnerHistory. Does not make sense. An IfcOrganisation is not a rooted element, and therefore cannot have an ownership history assigned to it.
- D - Category - IfcActorRole.UserDefinedRole. Perhaps better specified as “IfcOrganisation.Roles[0].Role”, with a way to denote if it is user defined. There are a few problems here: 1) what if more than one role exists? In the past, you had specified concatenation, but I understand this is not desired. 2) Shouldn’t you specify
Roleinstead ofUserDefinedRole? It makes much more sense thatUserDefinedRoleis only specified ifRole==USERDEFINED. - E - Email - IfcTelecomAddress.ElectronicMailAddresses. Again, better specified from the top-level relationship, i.e.
IfcOrganisation.Addresses[type="IfcTelecomAddress"][0]ElectronicMailAddresses[0]. Similar questions: what if more than one address is specified? What if more than one email is specified? In my example, I have denoted the zero’th index, to specify that in the spreadsheet mapping only the first (which is arbitrary) shall be represented. However, this should be clarified in the spec. - F - Phone - IfcTelecomAddress.TelephoneNumbers - See previous.
- G - ModelSoftware - IfcApplication.ApplicationFullName - How is this to be derived? There is no relationship between IfcOrganization and IfcApplication. Perhaps this should be n/a?
- H - ModelID - IfcOrganization is not rooted. This cannot make sense. Perhaps at a stretch you might mean IfcOrganization.Identification?
- I to O - same question as the email effectively, but reworded for IfcPostalAddress. However,
AddressLinesneeds clarification on the concatenation method (are we using;?) - P - CompanyURL - FMH_PSetCompany.URL. Apart from the inconsistent capitalisation of “Pset”, Psets cannot be assigned to IfcOrganization. Also, why is this a Pset? Shouldn’t it be IfcTelecomAddress.WWWHomePageURL instead?
I stopped here, as many of the other mapping tables probably have similar issues. Please let me know @bill.east if it makes sense.
2 Likes
@Moult Most excellent! These are exactly the precise and fine grained details that those participating in the Technical Team will contribute, once the project obtains the necessary sponsorships to formally begin. The first meeting of the Technical Team will organize the full review of the complete draft mapping to establish internationally agreed upon, objectively testable, 100% repeatable results.
1 Like
@bill.east cheers. So where do we find the technical team? Where do they discuss? Can I join the technical team? I’d like to join and help build this tool for objectively testable, 100% repeatable results and make it freely available.
Can I do this without becoming a sponsor, or do I need to be a sponsor first? If I need to be a sponsor, can I negotiate a non-financial sponsorship (i.e. I sponsor my time and development resources, but not financial) with @jwouellette ?
@Moult along with everyone else…
Please be patient. The project still has to be fully sponsored and funded before any further work is done. We are presenting the project at the Building Room 4 session on Tuesday, 23rd March at 16.00 UTC. Please go to The buildingSMART International Virtual Summit Spring 2021 to learn more.
@bill.east, Ines Azpeitia Gonzalez and I will be presenting more detail on the project then.
1 Like
Sounds good - was not aware of the project timeline. Looking forward to when this project moves forward.