Блог

В учебниках по программному обеспечению я читал, что NGSI-LD не является на 100% JSON-LD. Можете ли вы объяснить мне, в чем заключаются различия?

JSON-LD-это расширение для обозначения объектов JavaScript, которое позволяет выражать концепции связанных данных в формате JSON и обеспечивает формат, понятный как для человека, так и для компьютера. Это JSON-LD:

JSON-LD

 {
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
 

NGSI-LD-это API, который использует несколько форматов полезной нагрузки, но вот сущность Джона Леннона, выраженная с использованием «нормализованного» NGSI — LD-одного из нескольких форматов, которые должны поддерживать все контекстные брокеры NGSI (они также охватывают простые значения ключа JSON и GeoJSON, например — см. Ниже).

«нормализованный» NGSI-LD

ПОЛУЧИТЬ ../ngsi-ld/v1/entities/John_Lennon Тип содержимого: application/ld json

 {
   "@context":  [
     "https://json-ld.org/contexts/person.jsonld",
     "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
  ],
   "id": "http://dbpedia.org/resource/John_Lennon",
   "type": "Person",
   "name": {"type": "Property", "value": "John Lennon"},
   "born": {"type": "Property", "value": "1940-10-09"},
   "spouse": {
      "type": "Relationship", "object": 
      "http://dbpedia.org/resource/Cynthia_Lennon"
   }
}
 

Каждая полезная нагрузка NSGI-LD является допустимой JSON-LD. Однако этот «нормализованный» формат NGSI-LD имеет дополнительные правила и ограничения (например, все атрибуты должны иметь type значение Property или Relationship ), поэтому не все фрагменты JSON-LD являются допустимыми «нормализованными» NGSI-LD.

Подобно тому, как JSON-LD-это концепции связанных данных JSON плюс, NGSI-LD-это концепции связанных данных NGSI-v2 плюс.

Спецификация NGSI-LD описывает, как отправлять запросы контекстному брокеру и ожидаемый формат ответов. В NGSI существует 27 четко определенных операций. Кроме того, NGSI-LD определяет строгие определения таких терминов, как Подписка и Регистрация , Собственность и отношения, как временные метки должны храниться только в observedAt , географическое положение должно быть найдено в location атрибуте как GeoJSON Point и так далее.

JSON-LD-это только представление данных, оно не делает никаких предположений о том, как будет осуществляться доступ к полезной нагрузке или как она будет структурирована, помимо наличия атрибутов в формате JSON и @context атрибута.

Операции контекстного брокера с Контекстным брокером в «нормализованном» NGSI-LD могут предполагать, что основной контекст https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld считается частью запроса и обрабатывается последним и, следовательно, всегда переопределяет другие @context элементы. @context элемент также может быть представлен с помощью заголовка ссылки

Представления JSON-LD всегда должны содержать @context атрибут (в конце концов, именно это делает их application/ld json более простыми application/json ), и @context они обрабатываются в соответствии с порядком найденного массива элементов.

Поскольку NGSI-LD определяется как API, ответы на запросы NGSI-LD также могут быть возвращены в формате JSON application/json и application/geo json GeoJSON или как «нормализованные» или в виде пар ключ-значение с @context аннотациями и или без Properties них. Например, формат значений ключей вернет сущность John_Lennon следующим образом:

 {
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
 

 {
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
 

 {
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-73.975, 40.775556]
  },
  "properties": {
    "name": "John Lennon",
    "born": "1940-10-09",
    "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
  }
}