Rozszerzanie nalogów

W tym artykule użyto ontologii RealEstateCore opartej na języku DTDL dla inteligentnych budynków jako podstawy przykładów rozszerzania nalogów z nowymi właściwościami DTDL. Opisane tutaj techniki są jednak ogólne i mogą być stosowane do dowolnej części ontologii opartej na języku DTDL z dowolną funkcją DTDL zgodną z usługą Azure Digital Twins (właściwość, relacja, składnik).

Standardowe wdrożenia firmy Microsoft, takie jak ontologia RealEstateCore oparta na dtDL, to doskonały sposób na rozpoczęcie tworzenia rozwiązania IoT. Wdrożenia branżowe zapewniają bogaty zestaw interfejsów podstawowych, które są przeznaczone dla Twojej domeny i zaprojektowane do pracy z pudełkiem w usługach Azure IoT, takich jak Azure Digital Twins.

Istnieje jednak możliwość, że rozwiązanie może mieć określone potrzeby, które nie są objęte dziedziną ontologii branżowej. Możesz na przykład połączyć cyfrowe reprezentacje bliźniacze z modelami 3D przechowywanymi w osobnym systemie. W takim przypadku można rozszerzyć jedną z tych nalogów, aby dodać własne możliwości, zachowując jednocześnie wszystkie korzyści wynikające z oryginalnej ontologii.

Hierarchia przestrzeni RealEstateCore

W ontologii RealEstateCore opartej na języku DTDL hierarchia przestrzeni służy do definiowania różnych rodzajów przestrzeni: pomieszczeń, budynków, strefy itd. Hierarchia rozciąga się od każdego z tych modeli w celu zdefiniowania różnych rodzajów pomieszczeń, budynków i stref.

Część hierarchii wygląda podobnie do poniższego diagramu.

Aby uzyskać więcej informacji na temat ontologii RealEstateCore, zobacz Digital Twins Definition Language-based RealEstateCore ontology for smart buildings onhub (Architektura realEstateCore dla inteligentnych budynków w usłudze GitHub).

Rozszerzanie hierarchii przestrzeni RealEstateCore

Czasami rozwiązanie ma określone potrzeby, które nie są objęte ontologią branży. W takim przypadku rozszerzenie hierarchii umożliwia dalsze korzystanie z ontologii branżowej podczas dostosowywania jej do własnych potrzeb.

W tym artykule omówiono dwa różne przypadki, w których rozszerzenie hierarchii ontologii jest przydatne:

• Dodawanie nowych interfejsów dla pojęć, które nie są w branży ontologii.
• Dodawanie dodatkowych właściwości, relacji lub składników do istniejących interfejsów.

Dodawanie nowych interfejsów dla nowych pojęć

W takim przypadku chcesz dodać interfejsy dla pojęć potrzebnych dla rozwiązania, które nie są obecne w branży ontologii. Jeśli na przykład rozwiązanie ma inne typy pomieszczeń, które nie są reprezentowane w ontologii RealEstateCore opartej na języku DTDL, możesz je dodać, rozszerzając je bezpośrednio z interfejsów RealEstateCore.

W poniższym przykładzie przedstawiono rozwiązanie, które musi reprezentować "pomieszczenia fokusu", które nie są obecne w ontologii RealEstateCore. Pomieszczenie fokusowe to mała przestrzeń przeznaczona dla ludzi, aby skupić się na zadaniu przez kilka godzin naraz.

Aby rozszerzyć ontologię branżową przy użyciu tej nowej koncepcji, utwórz nowy interfejs, który rozciąga się od interfejsów w branży ontologii.

Po dodaniu interfejsu pomieszczenia fokusu rozszerzona hierarchia pokazuje nowy typ pokoju.

Dodawanie dodatkowych możliwości do istniejących interfejsów

W takim przypadku chcesz dodać więcej właściwości, relacji lub składników do interfejsów, które znajdują się w branży ontologii.

W tej sekcji zobaczysz dwa przykłady:

• Jeśli tworzysz rozwiązanie, które wyświetla rysunki 3D spacji, które już masz w istniejącym systemie, możesz skojarzyć każdą cyfrową reprezentację bliźniaczą z rysunkiem 3D (według identyfikatora), aby po wyświetleniu informacji o przestrzeni rozwiązanie mogło również pobrać rysunek 3D z istniejącego systemu.
• Jeśli twoje rozwiązanie musi śledzić stan sali konferencyjnej w trybie online/offline, możesz śledzić stan sali konferencyjnej do użycia w wyświetlaniu lub zapytaniach.

Oba przykłady można zaimplementować przy użyciu nowych właściwości: drawingId właściwości, która kojarzy rysunek 3D z cyfrową reprezentacją bliźniaczą i właściwością wskazującą online , czy sala konferencyjna jest w trybie online, czy nie.

Zazwyczaj nie chcesz bezpośrednio modyfikować ontologii branżowej, ponieważ chcesz mieć możliwość uwzględnienia aktualizacji w rozwiązaniu w przyszłości (co spowoduje zastąpienie dodatków). Zamiast tego tego tego rodzaje dodatków można wykonać we własnej hierarchii interfejsu, która rozciąga się na ontologię RealEstateCore opartą na języku DTDL. Każdy utworzony interfejs używa wielu dziedziczenia interfejsu w celu rozszerzenia nadrzędnego interfejsu RealEstateCore i interfejsu nadrzędnego z rozszerzonej hierarchii interfejsu. Takie podejście umożliwia korzystanie ze wspólnej ontologii branżowej i dodatków.

Aby rozszerzyć branżę, utwórz własne interfejsy, które rozszerzają interfejsy w branży ontologii i dodaj nowe możliwości do rozszerzonych interfejsów. Dla każdego interfejsu, który chcesz rozszerzyć, utwórz nowy interfejs. Interfejsy rozszerzone są zapisywane w języku DTDL (zobacz DTDL dla interfejsów rozszerzonych w dalszej części tego dokumentu).

Po rozszerzeniu części hierarchii pokazanej powyżej rozszerzona hierarchia wygląda jak na poniższym diagramie. Tutaj rozszerzony interfejs spacji drawingId dodaje właściwość, która będzie zawierać identyfikator, który kojarzy cyfrową reprezentację bliźniaczną z rysunkiem 3D. Ponadto interfejs ConferenceRoom dodaje online właściwość, która będzie zawierać stan online sali konferencyjnej. Dzięki dziedziczeniu interfejs ConferenceRoom zawiera wszystkie możliwości interfejsu RealEstateCore ConferenceRoom i wszystkie możliwości z rozszerzonego interfejsu space.

Nie musisz rozszerzać każdego interfejsu w branży ontologii, tylko tych, w których trzeba dodać nowe możliwości. Jeśli na przykład musisz dodać nową funkcję, taką jak arterial właściwość do interfejsu Hallway, możesz rozszerzyć ten interfejs bez rozszerzania innych interfejsów, które również rozciągają się od obszaru Pokój.

Relacje z interfejsami rozszerzonymi

Interfejsy rozszerzone mogą być również używane jako element docelowy dla relacji, nawet jeśli relacja jest pierwotnie modelowana w celu kierowania interfejsu podstawowego. Na przykład w ontologii RealEstateCore opartej na języku DTDL interfejs Apartament zawiera relację o nazwie , która jest przeznaczona dla interfejsu pokoju (pokazanego na poniższym diagramie). Pozwala to utworzyć graf pomieszczeń, aby utworzyć mieszkanie.

W oparciu o część hierarchii Pokój z poprzedniej sekcji, cyfrowy bliźniak Apartament może zawierać bliźniaki typu Pokój, a Hallway jest rozszerzeniem Pokoju (więc apartament może zawierać korytarze). Oznacza to również, że apartament może zawierać rozszerzony Korytarz z nieruchomością arterial , ponieważ rozszerzony Korytarz liczy się jako Hallway, ponieważ odwołuje się do oryginalnych relacji.

Korzystanie z hierarchii przestrzeni rozszerzonej

Podczas tworzenia cyfrowych reprezentacji bliźniaczych przy użyciu rozszerzonej hierarchii Space każdy model cyfrowej reprezentacji bliźniaczej będzie jednym z rozszerzonej hierarchii Przestrzeni (a nie oryginalnej ontologii branżowej) i będzie zawierać wszystkie możliwości z branży ontologii i rozszerzonych interfejsów za pośrednictwem dziedziczenia interfejsu.

Każdy model cyfrowej reprezentacji bliźniaczej będzie interfejsem z rozszerzonej hierarchii, pokazanym na poniższym diagramie.

Podczas wykonywania zapytań dotyczących cyfrowych reprezentacji bliźniaczych przy użyciu identyfikatora modelu ( IS_OF_MODEL operatora) należy użyć identyfikatorów modelu z hierarchii rozszerzonej. Na przykład SELECT * FROM DIGITALTWINS WHERE IS_OF_MODEL('dtmi:com:example:Office;1').

Współtworzenia oryginalnej ontologii

W niektórych przypadkach rozszerzysz ontologię branżową w sposób, który jest szeroko przydatny dla większości użytkowników ontologii. W takim przypadku należy rozważyć współtworzenia rozszerzeń z powrotem do oryginalnej ontologii. Każda ontologia ma inny proces współtworzenia, więc sprawdź repozytorium GitHub ontology pod kątem szczegółów współtworzenia.

Język DTDL dla nowych interfejsów

Kod DTDL dla nowych interfejsów, które rozciągają się bezpośrednio od ontologii branżowej, będzie wyglądać następująco.

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

Język DTDL dla interfejsów rozszerzonych

Kod DTDL dla interfejsów rozszerzonych, ograniczony do omówionej powyżej części, wygląda następująco.

[
  {
    "@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" 
  }
]

Następne kroki

Kontynuuj pracę na ścieżce tworzenia modeli na podstawie dzienników: pełna ścieżka programowania modelu.