After reading Dimitrie’s thesis in-depth, I was curious about developing an alternate Speckle Object-Model.
“…This can be traced to the way knowledge is developed and encapsulated in professions: the definition of beam will be different for an architect, a structural engineer or an asset manager. As Abbott would put it, each, when presented with information about a beam, will reshape it to fit the internal standards of their discipline and its body of knowledge (Abbott, 1992).”
This part from the Thesis is the most intriguing to me regarding this. Has someone successfully developed an alternate ObjectModel for their daily practices and wants to share it? How did you do it?
Hoping to see some good examples to further gather understanding in this regard.
Best regards from Germany,
OS BIM Manager
Hey @osbimmanager! I think there are examples in the industry of alternative object models, not necessarily speckle ones (even though they could, in theory, made speckle-compatible). IFC is one of them, BHoM is another, etc. We’ve heard rumours of other OMs for Speckle, but they were never made public
I think the good people from RHDV, for example, have or are extending the default Speckle object model (also a viable strategy). I’m cc’ing @dirksliepenbeek who recently asked a question related to a mooring point derived from a speckle point. I’m sure he could give you more info on that! @Ferdi_Meijer also worked on an application regarding zone security automation (if I recall correctly!) that also used a custom object model.
As a side commentary: from a product point of view, multiple object models are not conducive to the best user experience - especially in regards with the audience we’re finding ourselves serving currently. As a technological solution that defuses the politics behind professions and allows them to interchange information in a meaningful way, it works. Equally important for AEC is being able to have an object model that can be dynamically extended without the ceremony associated with a standard. That’s due to the “one-off”-ness of how we build as well as allowing for shared understanding to emerge “ad-hoc” between stakeholders (builders, contractors, fabricators, designers, etc.).
On practical note, if you’re after creating your own object model, ideally you’d start by extending the existing one - or letting us know where it sucks!
As @dimitrie mentioned, I am extending the Speckle object model indeed.
I do this because in my application I would like to send data of the MooringPoint instance. The MooringPoint class (ideally) inherits from the Point class and adds the attributes to it which make it a MooringPoint rather than a regular Point.
So in case of this application, I am using my own Object model of the application, and I map it to the most closely related models from the Speckle object model. If there is no closely related one, I would inherit from the Base Speckle object, which gives me the possibility to use my own defined objects in a Speckle context.
I actually agree with @dimitrie’s side commentary. I wouldn’t make this SpeckleMooringPoint if it was already existing. Ideally I would take learnings from industry standards such as IFC, or at least get together with other people who would use a SpeckleMooringPoint to agree on a standard we could share. But for now this serves the purpose.