hammar
commented
2 years ago Hi!
Caveat: the following is my personal interpretation, and while I contribute to this repo I am not employed by Microsoft or privy to internal discussions.
Q1
I think there may be a slight (very understandable!) confusion w.r.t the terminology here; DTDL v1 included a language-level construct called CapabilityModel, which could implement one or more Capability Model Interfaces, which in turn used Interfaces as schemas. My interpretation is that this first edition of the language focused more or less exclusively on describing sensor/actuator devices, and that in that modelling context a Capability was a natural built in language feature.
DTDL v2 is intended for use with a broader set of Azure technologies (e.g., Azure Digital Twins) that target not only such sensor/actuator devices but also broader modelling domains (e.g., the topology of a building, non-sensorized components within a piece of machinery, etc.). In such modelling contexts, always rooting Interfaces in CapabilityModels is not as natural. Consequently, for DTDL v2 this structure was simplified and a layer of indirection was removed, leaving only Interfaces and deprecating CapabilityModels and Capability Model Interfaces as language features.
Now, in the RealEstateCore models there is an Interface definition called Capability, the provided subclasses of which do describe capabilities within a building/BMS context (“TemperatureSensor”, “PositionActuator”, and so on). One can think of a Capability in RealEstateCore as analogous to a BMS “Point” (see, e.g., https://brickschema.org/ontology/1.2/classes/Point or other vocabularies that use such nomenclature). So RealEstateCore Capabilities fulfil roughly the same use as a DTDLv1 Capability Model would, but are not features of the DTDL language itself; but rather a set of pre-configured DTDL models that we provide.
Q2
As to the second question, how these models are used/instantiated – I have primarily used them in ADT; there you can upload them using the ADT Explorer (https://explorer.digitaltwins.azure.net/) or using the ADT APIs (https://docs.microsoft.com/en-us/azure/digital-twins/how-to-manage-model). The ModelUploader tool in the repo https://github.com/Azure/opendigitaltwins-tools/ could be used also if you prefer a CLI solution.
Once your models are loaded, you’d have to instantiate your twins and twin relationships based on the structure of your building: in ADT Explorer you can do that using point-and-click approaches or by uploading a JSON file containing your data. There are also APIs you can use: https://docs.microsoft.com/en-us/azure/digital-twins/how-to-manage-twin
Best,
Karl
sypks
Hello,
We noticed some contradictions between the underlying dtdl framework and opendigitaltwins-building. In particular, dtdl has orphaned the capability model with their update to: dtmi:dtdl:context;2 However, in digital twins building we noticed that the capability model has been kept.
Our questions:
Thank you for your time =)