Extension d’ontologies

Cet article utilise l’ontologie RealEstateCore basée sur le langage DTDL pour les bâtiments intelligents comme base pour des exemples d’extension d’ontologies avec de nouvelles propriétés DTDL. Toutefois, les techniques décrites ici sont générales et peuvent être appliquées à n’importe quelle partie d’une ontologie basée sur DTDL avec n’importe quelle fonctionnalité DTDL compatible avec Azure Digital Twins (propriété, relation, composant).

Les ontologies standard de Microsoft, telles que l’ontologie RealEstateCore basée sur DTDL, constituent un excellent moyen de commencer à créer votre solution IoT. Les ontologies du secteur fournissent un ensemble complet d’interfaces de base conçues pour votre domaine et conçues pour travailler à l’extérieur des services Azure IoT comme Azure Digital Twins.

Toutefois, il est possible que votre solution ait des besoins spécifiques non couverts par l’ontologie du secteur. Par exemple, vous pouvez souhaiter lier vos jumeaux numériques à des modèles 3D stockés dans un système distinct. Dans ce cas, vous pouvez étendre l’une de ces ontologies pour ajouter vos propres fonctionnalités tout en conservant tous les avantages de l’ontologie d’origine.

Hiérarchie Space de RealEstateCore

Dans l’ontologie RealEstateCore DTDL, la hiérarchie Space permet de définir différents genres d’espace : pièces, bâtiments, zones, etc. La hiérarchie s’étend à partir de chacun de ces modèles pour définir différents genres de pièce, bâtiment et zone.

Une partie de la hiérarchie ressemble au diagramme ci-dessous.

Pour plus d’informations sur l’ontologie RealEstateCore, consultez Ontologie RealEstateCore basée sur le langage de définition Digital Twins pour les bâtiments intelligents sur GitHub.

Extension de la hiérarchie Space de RealEstateCore

Parfois, votre solution a des besoins spécifiques qui ne sont pas couverts par l’ontologie du secteur. Dans ce cas, l’extension de la hiérarchie vous permet de continuer à utiliser l’ontologie du secteur tout en la personnalisant selon vos besoins.

Dans cet article, nous abordons deux cas distincts où l’extension de la hiérarchie de l’ontologie est utile :

• Ajout de nouvelles interfaces pour les concepts qui ne font pas partie de l’ontologie du secteur.
• Ajout de propriétés, de relations ou de composants supplémentaires à des interfaces existantes.

Ajouter de nouvelles interfaces pour de nouveaux concepts

Dans ce cas, vous souhaitez ajouter des interfaces pour les concepts nécessaires à votre solution qui ne sont pas présents dans l’ontologie du secteur. Par exemple, si votre solution comporte d’autres types de pièce qui ne sont pas représentés dans l’ontologie RealEstateCore DTDL, vous pouvez les ajouter en les étendant directement à partir des interfaces RealEstateCore.

L’exemple ci-dessous décrit une solution qui doit représenter des « salles de concentration », lesquelles ne font pas partie de l’ontologie RealEstateCore. Une salle de concentration est un petit espace conçu pour permettre aux gens de se focaliser sur une tâche pendant quelques heures.

Pour étendre l’ontologie du secteur avec ce nouveau concept, créez une interface qui s’étend à partir des interfaces de l’ontologie du secteur.

Une fois l’interface de la salle de concentration ajoutée, la hiérarchie étendue montre le nouveau type de salle.

Ajouter des fonctionnalités supplémentaires à des interfaces existantes

Dans ce cas, vous souhaitez ajouter d’autres propriétés, relations ou composants aux interfaces qui se trouvent dans l’ontologie du secteur.

Dans cette section, vous allez voir deux exemples :

• Si vous créez une solution qui affiche des dessins 3D d’espaces qui existent déjà dans un système, vous pouvez associer chaque jumeau numérique à son dessin 3D (par ID). Ainsi, quand la solution affiche des informations relatives à l’espace, elle peut également récupérer le dessin 3D du système existant.
• Si votre solution doit effectuer le suivi de l’état en ligne/hors connexion des salles de conférence, vous pouvez suivre l’état d’une salle de conférence pour l’afficher ou l’utiliser dans des requêtes.

Vous pouvez implémenter les deux exemples avec de nouvelles propriétés : une propriété drawingId qui associe le dessin 3D au jumeau numérique, et une propriété online (en ligne) qui indique si la salle de conférence est en ligne ou non.

En règle générale, il est déconseillé de modifier directement l’ontologie du secteur, car vous pouvez être amené à incorporer plus tard des mises à jour dans votre solution (ce qui entraîne le remplacement de vos ajouts). À la place, vous pouvez effectuer ce genre d’ajout dans votre propre hiérarchie d’interface, laquelle est une extension de l’ontologie RealEstateCore DTDL. Chaque interface que vous créez utilise plusieurs héritages d’interface pour étendre son interface RealEstateCore parente et son interface parente à partir de votre hiérarchie d’interface étendue. Cette approche vous permet d’utiliser à la fois l’ontologie du secteur et vos ajouts.

Pour étendre l’ontologie du secteur, créez vos propres interfaces qui s’étendent à partir des interfaces de l’ontologie du secteur, et ajoutez les nouvelles fonctionnalités à vos interfaces étendues. Pour chaque interface à étendre, créez une interface. Les interfaces étendues sont écrites en DTDL (consultez Langage DTDL pour les interfaces étendues plus loin dans ce document).

Après l’extension de la partie de la hiérarchie présentée ci-dessus, la hiérarchie étendue ressemble au diagramme ci-dessous. Ici, l’interface Space étendue ajoute la propriété drawingId qui va contenir un ID associant le jumeau numérique au dessin 3D. De plus, l’interface ConferenceRoom ajoute une propriété online, qui contient l’état en ligne de la salle de conférence. Grâce à l’héritage, l’interface ConferenceRoom contient toutes les fonctionnalités de l’interface ConferenceRoom de RealEstateCore ainsi que toutes les fonctionnalités de l’interface Space étendue.

Vous n’avez pas à étendre chaque interface dans l’ontologie du secteur, mais uniquement celles pour lesquelles vous devez ajouter de nouvelles fonctionnalités. Par exemple, si vous devez ajouter une nouvelle fonctionnalité, comme une propriété arterial à l’interface Hallway, vous pouvez étendre cette interface sans étendre les autres interfaces qui s’étendent également à partir de Room.

Relations avec les interfaces étendues

Les interfaces étendues peuvent également être utilisées comme cible pour les relations, même si la relation est initialement modélisée pour cibler une interface de base. Par exemple, dans l’ontologie RealEstateCore basée sur DTDL, l’interface Apartment contient une relation nommée includes qui cible une interface Room (illustrée dans le diagramme ci-dessous). Cela vous permet de créer un graphique de pièces pour composer l’appartement.

En fonction de la partie de la hiérarchie Room de la section précédente, un jumeau numérique Apartment peut inclure un jumeau de type Room, et Hallway est une extension de Room (de sorte qu’un appartement peut inclure des couloirs). Cela signifie également qu’un Apartment peut inclure un Hallway étendu avec la propriété arterial, car un Hallway étendu compte comme un Hallway, car il est référencé dans les relations d’origine.

Utilisation de la hiérarchie Space étendue

Quand vous créez des jumeaux numériques à l’aide de la hiérarchie Space étendue, le modèle de chaque jumeau numérique est celui de la hiérarchie Space étendue (et non celui de l’ontologie du secteur d’origine). Il comprend toutes les fonctionnalités de l’ontologie du secteur ainsi que les interfaces étendues via l’héritage d’interface.

Le modèle de chaque jumeau numérique correspond à une interface provenant de la hiérarchie étendue, comme illustré dans le diagramme ci-dessous.

Durant l’interrogation de jumeaux numériques à l’aide de l’ID de modèle (opérateur IS_OF_MODEL), les ID de modèle de la hiérarchie étendue doivent être utilisés. Par exemple : SELECT * FROM DIGITALTWINS WHERE IS_OF_MODEL('dtmi:com:example:Office;1').

Contribution à l’ontologie d’origine

Parfois, vous allez étendre l’ontologie du secteur de manière très utile pour la plupart des utilisateurs de l’ontologie. Dans ce cas, vos extensions peuvent contribuer à l’ontologie d’origine. Dans la mesure où chaque ontologie a un processus de contribution différent, consultez le dépôt GitHub de l’ontologie pour plus d’informations sur cet aspect.

Langage DTDL des nouvelles interfaces

Le langage DTDL des nouvelles interfaces qui s’étendent directement à partir de l’ontologie du secteur ressemble à ce qui suit.

{
  "@id": "dtmi:com:example:FocusRoom;1", 
  "@type": "interface", 
  "extends": "dtmi:digitaltwins:rec_3_3:building:Office;1", 
  "@context": "dtmi:dtdl:context;2" 
} 

Langage DTDL des interfaces étendues

Le langage DTDL des interfaces étendues, limité à la partie décrite ci-dessus, ressemble à ceci.

[
  {
    "@id": "dtmi:com:example:Space;1",
    "@type": "Interface",
    "extends": "dtmi:digitaltwins:rec_3_3:core:Space;1",
    "contents": [
      {
        "@type": "Property",
        "name": "drawingid",
        "schema": "string"
      }
    ],
    "@context": "dtmi:dtdl:context;2"
  },
  {
    "@id": "dtmi:com:example:Room;1",
    "@type": "Interface",
    "extends": [
      "dtmi:digitaltwins:rec_3_3:core:Room;1",
      "dtmi:com:example:Space;1"
    ],
    "@context": "dtmi:dtdl:context;2"
  },
  {
    "@id": "dtmi:com:example:ConferenceRoom;1",
    "@type": "Interface",
    "extends": [
      "dtmi:digitaltwins:rec_3_3:building:ConferenceRoom;1",
      "dtmi:com:example:Room;1"
    ],
    "contents": [
      {
        "@type": "Property",
        "name": "online",
        "schema": "boolean"
      }
    ],
    "@context": "dtmi:dtdl:context;2"
  },
  {
    "@id": "dtmi:com:example:Office;1",
    "@type": "Interface",
    "extends": [
      "dtmi:digitaltwins:rec_3_3:building:Office;1", 
      "dtmi:com:example:Room;1" 
    ],
    "@context": "dtmi:dtdl:context;2" 
  }, 
  {
    "@id": "dtmi:com:example:FocusRoom;1", 
    "@type": "Interface", 
    "extends": "dtmi:com:example:Office;1", 
    "@context": "dtmi:dtdl:context;2" 
  }
]

Étapes suivantes

Continuez sur le chemin de développement de modèles basés sur des ontologies : chemin de développement de modèle complet.