是否有将 FIWARE NGSI-LD 实体表示迁移到 NGSI-v2 的标准化方法?
Is there a standardized way to migrate FIWARE NGSI-LD entity representations to NGSI-v2?
我已经在 FIWARE 社区找到 this script,它将 NGSI-v2 规范化表示转换为 NGSI-LD 表示。
相反的方向有类似的东西吗?我知道大多数步骤都可以倒着做。但是,我不确定转换回 "type": "Property"
节点的通常过程。
例如给定 NGSI-v2 实体表示:
{
"id": "Store:001",
"type": "Store",
"name": {
"type": "Text",
"value": "Checkpoint Markt"
}
}
运行 上面的脚本将导致:
{
"@context": [
https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
],
"id": "urn:ngsi-ld:Store:Store:001",
"type": "Store",
"name": {
"type": "Property,
"value": "Checkpoint Markt"
}
}
所以在这种情况下,很难将 "type": "Property"
节点转换回 "type": "Text"
。
但给出以下 NGSI-v2 实体表示:
{
"type": "Store",
"id": "Store:002",
"address": {
"type": "PostalAddress",
"value": {
"streetAddress": "Friedrichstraße 44",
"addressRegion": "Berlin",
"addressLocality": "Kreuzberg",
"postalCode": "10969"
}
}
}
将转换为:
{
"@context": [
https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
],
"id": "urn:ngsi-ld:Store:Store:002",
"type": "Store",
"address": {
"type": "Property",
"value": {
"streetAddress": "Friedrichstra\u00dfe 44",
"addressRegion": "Berlin",
"addressLocality": "Kreuzberg",
"postalCode": "10969",
"type": "PostalAddress"
}
}
}
这是由于脚本中的特殊情况造成的:
if attr['type'] == 'PostalAddress':
ld_attr['value']['type'] = 'PostalAddress'
是否可以在其值中使用这样的 "type": _
对扩展所有已转换的属性?或者是否有原因将代码限制为“PostalAddress”类型?否则,这些 "type": "Property"
个节点是否有任何规范?
我不是 NGSI-LD 方面的专家,但这种特殊情况下的转换可以通过以下方式解决:
- 如果
Property
在其 value
中有一个 type
然后将它用于 NGSIv2 中的属性类型(如您显示的“PostalAddress”案例)
- 如果
Property
在其 value
中没有任何 type
则使用 type
在 NGSIv2 specification “部分表示”中指定的默认类型作为属性“ 部分。例如,如果 value
是 "Checkpoint Markt"
(这是一个字符串),那么 NGSIv2 中的属性类型将对应于 "Text"
.
从 NGSI-LD 转换为 NGSIv2 不是一个好主意。
NGSI-LD >> NGSIv2 ...可能是这种情况,您可能需要从 NGSIv2 转换为 NGSI-LD,以便您更具互操作性,但反过来...您可能需要重新考虑如果这是明智的...
我已经在 FIWARE 社区找到 this script,它将 NGSI-v2 规范化表示转换为 NGSI-LD 表示。
相反的方向有类似的东西吗?我知道大多数步骤都可以倒着做。但是,我不确定转换回 "type": "Property"
节点的通常过程。
例如给定 NGSI-v2 实体表示:
{
"id": "Store:001",
"type": "Store",
"name": {
"type": "Text",
"value": "Checkpoint Markt"
}
}
运行 上面的脚本将导致:
{
"@context": [
https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
],
"id": "urn:ngsi-ld:Store:Store:001",
"type": "Store",
"name": {
"type": "Property,
"value": "Checkpoint Markt"
}
}
所以在这种情况下,很难将 "type": "Property"
节点转换回 "type": "Text"
。
但给出以下 NGSI-v2 实体表示:
{
"type": "Store",
"id": "Store:002",
"address": {
"type": "PostalAddress",
"value": {
"streetAddress": "Friedrichstraße 44",
"addressRegion": "Berlin",
"addressLocality": "Kreuzberg",
"postalCode": "10969"
}
}
}
将转换为:
{
"@context": [
https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
],
"id": "urn:ngsi-ld:Store:Store:002",
"type": "Store",
"address": {
"type": "Property",
"value": {
"streetAddress": "Friedrichstra\u00dfe 44",
"addressRegion": "Berlin",
"addressLocality": "Kreuzberg",
"postalCode": "10969",
"type": "PostalAddress"
}
}
}
这是由于脚本中的特殊情况造成的:
if attr['type'] == 'PostalAddress':
ld_attr['value']['type'] = 'PostalAddress'
是否可以在其值中使用这样的 "type": _
对扩展所有已转换的属性?或者是否有原因将代码限制为“PostalAddress”类型?否则,这些 "type": "Property"
个节点是否有任何规范?
我不是 NGSI-LD 方面的专家,但这种特殊情况下的转换可以通过以下方式解决:
- 如果
Property
在其value
中有一个type
然后将它用于 NGSIv2 中的属性类型(如您显示的“PostalAddress”案例) - 如果
Property
在其value
中没有任何type
则使用type
在 NGSIv2 specification “部分表示”中指定的默认类型作为属性“ 部分。例如,如果value
是"Checkpoint Markt"
(这是一个字符串),那么 NGSIv2 中的属性类型将对应于"Text"
.
从 NGSI-LD 转换为 NGSIv2 不是一个好主意。
NGSI-LD >> NGSIv2 ...可能是这种情况,您可能需要从 NGSIv2 转换为 NGSI-LD,以便您更具互操作性,但反过来...您可能需要重新考虑如果这是明智的...