2 months, 3 weeks ago FritzMantelParticipant
I was wondering how Bamm compares to the W3C WoT “Thing Description” and “Thing Model” standard?
Seems like the Web of Things standard is gaining a lot of traction (eg Microsoft also joined the working group recently to consolidate their DTDL with W3C WoT) and Bamm seems to aim solving very similar problems.
2 months, 3 weeks ago Andreas TextorParticipant
an overlap between the W3C WoT Things Description (TD) Recommendation and the BAMM Aspect Meta Model certainly exists, and parallels between certain concepts from both specifications can be drawn, but there are also considerable differences between goals, architecture and the technical details.
Let’s first look at the similarities: Both can be used to describe “things”, i.e., logical or physical things. TD’s Property Affordances can be compared to BAMM Properties, TD Action Affordances to BAMM Operations and TD Events can be compared to BAMM Events. Both specifications describe a meta model/vocabulary that can be used to express a model (“Aspect Model” and “Thing Description”, respectively). Also, both specifcations make use of human-readable attributes such as titles and descriptions.
Now, there are also fundamental differences:
Goals and abstraction level:
TD makes no big fuzz: A TD describes a thing and its identifier (a URI) and capabilities, such as properties, actions and events and where these things can be accessed. Using one of multiple possible protocol bindings, the corresonding data can be accessed.
In BAMM’s context, Aspect Models explicitly do not identify a thing (which we would here call a “digital twin”): this is out of scope. Instead, how digital twins are managed, identified and referenced can depend heavily on the architecture of the system. Each digital twin can have any number of aspects, each of which is described by an Aspect Model. An Aspect Model describes exactly this – one aspect of the represented thing. This means that aspects can be mixed and matched as necessary, and during the life cycle of a digital twin aspects can be added and removed. This is not possible or at least not envisaged with TD.
Modeling formalism and datatypes:
TD is built on JSON and JSON-LD, and makes use of a small number of datatypes defined by XML Schema (
boolean). This approach has the advantage of reducing complexity to a minimum, as JSON can be considered a baseline format. The selection of XSD types maps nicely to JSON datatypes. Aspect Models on the other hand are defined using RDF and the Turtle syntax, which is better suited for human editing and provides features such as editing without excessive nesting and using comments, but comes with the complexity of the format for implementers. JSON-LD is easily parseable as JSON but to understand it, you need to understand RDF anyways. BAMM also builds on XSD types, but uses a much richer type hierarchy subset of XSD’s type tree.
Semantics and expressiveness:
BAMM was intended from the beginning as a language to describe models that serve as both domain ontologies and schema descriptions. This is why semantics that are captured as named elements (i.e. BAMM Characteristics). The meta model is built so that in an Aspect Model, each Property must be semantically described – every Property must have a Characteristic. Furthermore, by having Characteristics as separate model elements (instead of, for example, directly attaching the Characteristic’s attributes to the Property itself), modeling practice of clean structure and reuse of elements is fostered. In TD, semantics are realised as “Semantic Annotations”: Arbitrary external vocabularies can be included and elements from them can be “attached” to Class instances of Thing Descriptions. These are optional, so usability of TDs for capturing context/domain semantics depends solely on a modeler’s rigor. What is worse, there is no formalism specified that can be used for the vocabularies used in semantic annotations, which means that there is no generic way tooling or services can be implemented that effectively make use of the semantic annotations, which in turn strongly reduces their usefulness.
To summarize and give my personal opinion: For simpler or closed (as in: implementation of the overall system is completely in the hands of one party) used cases, WoT TD can be the specification of choice, since it has a lower learning curve: Things/Twins and their “properties” are specified centrally in one model, which you can use to implement software. However, if you want to have the flexibility to identify things/twins as required in your context, combine aspects as necessary and decouple aspects and their datasources from the things/twins they apply to, reuse model elements (which allows reviews and releases of model building blocks!), and have proper semantic descriptions in the model, you should give BAMM-based Aspect Models a try.
2 months, 3 weeks ago FritzMantelParticipant
Thank you very much for the comprehensive answer, really gave me some more insights about the goals and focus areas of BAMM.
I think the learning curve also of Web of Things is quite steep, it however is more “applicable” for me because of many available examples and use cases.
And maybe also because it also specifies with the TD quite a lot about how to access concrete “thing” instances.
What you referred to regarding the additional benefits of the BAMM aspect models: I think those also are all covered by the WoT “Thing Model” concept currently added in the 1.1 version of the specification, also supporting inheritance, importing and composing from and of other Thing Models, TDs being instances of those TMs.
I agree that using such methods is crucial for modeling things or aspects and it is great that BAMM also has that topic covered.
Could you maybe point me to some examples of BAMM aspect models and how to provide implementations of eg digital twins following the aspect models?
Really appreciating the forum and the possibility to get in contact.
2 months, 2 weeks ago Romy MlinzkKeymaster
Thank you, Andreas! I also learned a lot. Very helpful!
You must be logged in to reply to this topic.