Refactor Core @Context terms to https based namespace and use fragments for term URIs
Background:
We plan to use "https://uri.etsi.org/ngsi-ld/v1"
as a shortcut URI to redirect (through content negotiation) to https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld (already asked to ETSI)
If, for consistency, we migrate our Core @context terms to https schema then our terms will look like
"Property": "https://uri.etsi.org/ngsi-ld/Property"
or whatever.
So for some people it could be misleading to use "https://uri.etsi.org/ngsi-ld/v1"
as it could seem that a v1
@context term would exist when it doesn't. Also, imagine the, unlikely, event that some introduces a new API term named v1
. So it would be good, consistency-wise, to use a more concrete path for core @context terms. And also, using URI fragments, could be a good idea as W3C WoT is doing, see https://github.com/w3c/wot-thing-description/blob/master/context/td-context.jsonld
A proposed new path for our @context terms would be
"https:/uri.etsi.org/ngsi-ld/core"
and with URI fragment representation it would look like as follows
"Property": "https://uri.etsi.org/ngsi-ld/core#Property"
with URI paths it would look like as follows
"Property": "https://uri.etsi.org/ngsi-ld/core/Property"
A separate discussion is whether we should declare our Core @context using URI prefixes or not (performance wise).
The different options are summarized below.
Option 1. No prefix and Fragments
"@context" : {
"Property": "https:/uri.etsi.org/ngsi-ld/core#Property",
...
}
Option 2. Prefix and Fragments
"@context" : {
"ngsi-ld": "https:/uri.etsi.org/ngsi-ld/core#",
"Property": "ngsi-ld:Property",
...
}
Option 3. No prefix and regular URI paths (Closest to what currently have)
"@context" : {
"Property": "https:/uri.etsi.org/ngsi-ld/core/Property",
...
}
Option 4. Prefix and regular URI paths
"@context" : {
"ngsi-ld": "https:/uri.etsi.org/ngsi-ld/core/"
"Property": "ngsi-ld:Property",
...
}