allow a property set with appropriate schema and command to be attached to an issue

[buildingsmart]

allow a property set with appropriate schema and command to be attached to an issue

[linhard]

that scenario is already covered by the new BCF 2.0
-> Software A sends a topic -> e.g. "check space properties"
-> topic "check space properties" has a component "space" (using the space GUID)
-> Software B (space checking tool) receives the topic
-> Software B creates a new topic (accept new properties for the space)
-> New topic (B) has the BIM-Snippet attached
-> New topic (B) has a component "space" (using the space GUID)
-> New topic (B) has also the information that it is related to the topic from software A send previously
-> Software A receive the New topic (B)
-> Software A knows that the New topic (B) is related to its topic software A send previously
-> Software A knows also the component "space" (using the space GUID)
-> Software A can assign the BIM-Snippet to the component "space"

[TLiebich]

two questions:

1. regarding the BIM snippet:

   • is it necessary or required to publish a schema for the BIM snippet?
   • if yes, where is it published?
   • how does a software declare, whether it supports such a snippet?
   • as a user - how do I know, whether a BCF2.0 capable software
     does support one, many, any BIM snippets?

2. how does Software A know what to do with the BIM snippet?

   • is the publication (if it is published) enough?
   • or is there a need for an agreement of an action keyword?

Am 16.12.2013 12:04, schrieb linhard:

that scenario is already covered by the new BCF 2.0
-> Software A sends a topic -> e.g. "check space properties"
-> topic "check space properties" has a component "space" (using the
space GUID)
-> Software B (space checking tool) receives the topic
-> Software B creates a new topic (accept new properties for the space)
-> New topic (B) has the BIM-Snippet attached
-> New topic (B) has a component "space" (using the space GUID)
-> New topic (B) has also the information that it is related to the
topic from software A send previously
-> Software A receive the New topic (B)
-> Software A knows that the New topic (B) is related to its topic
software A send previously
-> Software A knows also the component "space" (using the space GUID)
-> Software A can assign the BIM-Snippet to the component "space"

—
Reply to this email directly or view it on GitHub
#18 (comment).

[berlotti]

Is this a realistic use case? Does the original (software A owner) modeler accept changes on his objects (with or without reviewing it)? Doesn't he need to have the mandate or option to decide about his model?
In my opinion the strong added value of BCF is that it communicates 'issues' of a model. Issues only; not parts of the model, not suggestions, additions, whatever. The modeling is done by the owner/modeler of the original model.
I sure see the added value of the 'snippets' concept in BCF 2.0 but still have to see if the industry will actually use this. I can already hear the questions about legal liability when software B changes (parts) of the model in software A. When this is really going to be used, and users start te experience limitations, it would be great to evolve this feature. For now I would stick with what it is and don't create an overkill. Listen to the users instead of shoving them technical possibilities they might not even want.

[berlotti]

Sorry for closing. Pushed the wrong button.

[pasi-paasiala]

I think this is a good use of BCF. We are dealing with property sets. We could think that in a collaborative project one software "owns" certain property sets, for example space requirements. Other software imports these requirements and the designers can base the design on these requirements. The designers then wouldn't need to refer to any other documentation to get these requirements. They would be directly associated to the correct entities, e.g., spaces.

[linhard]

two questions:

1. regarding the BIM snippet: - is it necessary or required to publish a schema for the BIM snippet?
   if yes, where is it published?
   => it is a mandatory tag "ReferenceSchema" in Markup.xsd
   => p.e. "http://www.iai-tech.org/ifcXML/IFC2x3/FINAL"
   => maybe we should think here in the direction of a MVD / Add on
   => maybe that could be an issue in the currently ongoing discussion mvdXML 1.1 ?

2. how does a software declare, whether it supports such a snippet? - as a user - how do I know, whether a BCF2.0 capable software does support one, many, any BIM snippets?
   => Software supports MVD / Add on

3. how does Software A know what to do with the BIM snippet? - is the publication (if it is published) enough? - or is there a need for an agreement of an action keyword?
   => Iam not very deep in mvdXML 1.1. but could that be an issue there ?

[TLiebich]

about user vs. technology driven:

• the request to have a possibility to update property sets in the
  original BIM authoring tool came from users of energy calculation software.
  the software imports IFC spaces (among others) and calculates the
  heat gain/losses per room, these properties are important to following
  processes
  right now, you can export an excel sheet and then type (or
  cut&paste) the values back into your BIM software, since you need it for
  e.g. layout of the heating system
• my assumption of BCF is, that the user will always be asked whether to
  accept an issue resolution, or not (so no silent change of values)

about Reference schema

• my proposal would be to use simple ifcXML, and publish the XSD at
  buildingsmart-tech.org
  currently the ifcXML4 (complete schema) is published at:
  http://www.buildingsmart-tech.org/ifcXML/IFC4/final
  a new directory for simple-ifcXML could be generated there

to 2) and 3)

• does this mean, there will be a specific "MVD" for BCF?
  I think there is an open issue with conformance testing and policy
  regarding the BIM snippets and the action requests
  it is not an mvdXML issue, it is a BCF issue (mvdXML only generates
  the simple ifcXML schema, it does not determine, how such actions are to
  be supported within BCF)

regards
Thomas

Am 16.12.2013 14:39, schrieb linhard:

two questions:

1. regarding the BIM snippet: - is it necessary or required to publish
   a schema for the BIM snippet?
   if yes, where is it published?
   => it is a mandatory tag "ReferenceSchema" in Markup.xsd
   => p.e. "http://www.iai-tech.org/ifcXML/IFC2x3/FINAL"
   => maybe we should think here in the direction of a MVD / Add on
   => maybe that could be an issue in the currently ongoing discussion
   mvdXML 1.1 ?

2. how does a software declare, whether it supports such a snippet? -
   as a user - how do I know, whether a BCF2.0 capable software does
   support one, many, any BIM snippets?
   => Software supports MVD / Add on

3. how does Software A know what to do with the BIM snippet? - is the
   publication (if it is published) enough? - or is there a need for an
   agreement of an action keyword?
   => Iam not very deep in mvdXML 1.1. but could that be an issue there ?

—
Reply to this email directly or view it on GitHub
#18 (comment).

Signature

beste Grüße / kind regards

Dr.-Ing. Thomas Liebich
Geschäftsführer / Director

---

AEC3 Deutschland GmbH
AG München, Handelsregister HRB 164221
Geschäftsführer: Dr. Thomas Liebich, Kerstin Hausknecht

Wendl-Dietrich-Str. 16, D-80634 München
Tel: [phone]
Fax: [phone]

E-Mail: [email protected] mailto:[email protected]
Internet: www.aec3.de http://www.aec3.de

Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
die E-Mail (einschließlich etwaiger Anhänge) von Ihrem System. | /This
email and any attachments are confidential to the intended recipient and
may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. You should not copy it
or use it for any purpose nor disclose or distribute its contents to any
other person./

---

[theoryshaw]

I believe BCF should not be relegated to 'issues only' as @berlotti suggests.

I think BCF is a perfect fledgling format to start introducing bidirection/roundrip content flow between BIM applications.

...and would obviously agree with @TLiebich that "that the user will always be asked whether to
accept an issue resolution, or not (so no silent change of values)"

Would also 2nd what @linhard @TLiebich suggested about developing a #roundtripMVD associated with the BCF.

Because the format is relatively new and not overwrought and gaining user traction, one would think there would be less fiction adopting a simple, barebones MVD--verses the major commitment of something like Coordination View Version 2.0 MVD certification, for example.

Would also like to add, as was suggested in the comment here, that i think the certification of this #roundtripMVD, if it existed, be highly tethered to a community sourced and curated set of IFC/BCF files. I believe this is critical, because it provides a conduit to bring the 'super-user' into these conversations.

[gschleusner]

+1 for the suggestions by @berlotti @linhard and @TLiebich.

We actually developed our own plugin initially and have been packing extra stuff into the BCF just so we can guide users to one format instead of having Random XML files that relate to a host of separate plugins. In general I think that BCF should broaden as others have suggested to not only be seen as a physical coordination/checking tool to but as a transport format to send various types of information about model elements.

I would suggest an approach that allow for BCF to be extensible as needed. Applications would simply need to indicate that they support one or more of the extensions. Some examples of what we have done and would like to see.

1. Selection - This is supper simple data set that is simply saying "These items are what i'm referring to." There isn't an associated issue as it must less formal.
2. Color by - This has 3 incarnations, color by element ID or color by attribute value, color by status. This can be combined with an issue so on a project we can do a few things.
   A. Communicate standard object colors between software used in coordination.
   B: Transmit,aligned color values for issues - Example - All failures are "Red"
3. Suggested Parameter/Attribute Value- If for instance an element type is correct but a fire rating or hardware value is incorrect and you happen to find it in Solibri , we'd want to allow the user to give structured feedback in the form of a suggested property value. This would go along with the other request to update parameter values in the authoring application. I'd agree that the user would need to confirm the changes.
4. Required Properties and agreed values. I have spoke with Leon about this in the past as a more advanced form of MVDXML but the general Idea is that at the project level you could define the property and modeling requirements for entity types and pass that between authoring and checking applications.

Just my thoughts.

Greg

[gschleusner]

@linhard clued me into the fact that BIM Snippits can be any type of file so I guess I'm just advocating for a way to "register" what a particular Snippet type does and how it should be used when seen by another application.

[TLiebich]

support @gschleusner for

1. the different levels of BCF2.0 support, those need to be documented (e.g. as conformance classes), so an BCF compliant application can declare, which level of BCF its supports
2. there needs to be a way to declare the a) type of action, and b) schema of the attachment

in the example - level 3 about - it should be defined
a) an action type "override element properties", and b) an (ifc)XML (partial) schema, that defines the data structure of the XML data snippet (e.g. an (ifc)XML file containing the suggested attribute name/values and the GUID of the model element.

[pasi-paasiala]

Sorry I closed this by mistake. I still think this is a good idea.