fix: expectations and exclusions in tutorial 102 - NGSI-LD - Working with context

[bobeal]

• terms used as values in the address property (streetAddress, ...) are not in ngsi-context.jsonld. thus, when they are created with this context, they are expanded using the default vocab from the core context (https://uri.etsi.org/ngsi-ld/default-context/streetAddress and not https://schema.org/streetAddress) and when compacting without specifying a context, they are "correctly" compacted (streetAddress). See this link for a demo in the JSON-LD playground.
• when using the json-context.jsonld context, https://schema.org/name and https://uri.fiware.org/ns/dataModels#category are respectively compacted to schema:name and fiware:category. See this link for a demo in the JSON-LD playground
• different version of the core context used by a context broker raises error. added exclusions on this field, but there may be better ways to handle this.

[flopezag]

I was working on those tutorials to improve the execution and resolve some issues. At the moment, I prefer to check the @context because I found some discrepancies.

Keep in mind that we are testing the tutorials not the functionality of the brokers.

[bobeal]

I was working on those tutorials to improve the execution and resolve some issues. At the moment, I prefer to check the @context because I found some discrepancies.

Keep in mind that we are testing the tutorials not the functionality of the brokers.

The first two points of the PR are strictly about NGSI-LD compliance, nothing related with the brokers.

And you are testing the tutorials ... using context brokers. So it is a bit harsh to consider a broker is failing whereas it is just not using the same default version of the core context.

[bobeal]

synced with last version on develop.

[bobeal]

any news on this PR?

[bobeal]

I updated some expectations in the PR:

• Following changes in this commit, and more specifically in the following two lines
• Some expectations add the core context in the payload, which is not correct since the core context is already included in the context provided in the query

I tested with Scorpio and Stellio which both return the same results. Since they use a JSON-LD compliant library (a custom version of JSONLD-Java for Scorpio and Titanium for Stellio), we can be confident that these are the correct expectations.

[bobeal]

Up!

[jason-fox]

I believe that when we send Accept: application/ld+json , the response should always be a fully valid JSON-LD document, therefore the context must include the core @context as part of an array.

"@context": [
            "http://context/ngsi-context.jsonld",
            "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld"
]

The reasoning is that terms such as location, type, Point and coordinates are not defined in the user context, so, for example looking at response 7, the proposed "@context": "http://context/ngsi-context.jsonld" is insufficient.

Similarly if a response was returned with just a user @context, but the response also contained terms not defined in the user @context, then without the core @context , there is no certainty a catch all @vocab term will be present. That means running a further expansion/compaction operation on the received data would just delete that missing term's attribute as undefined.

What is subject for debate, is Accept: application/ld+json when no user context is defined - I currently think that either of these responses are vaild - JSON-LD spec doesn't seem to mandate single element array reduction on @context

"@context": [
            "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld"
]

OR

"@context": "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld"

[bobeal]

I believe that when we send Accept: application/ld+json , the response should always be a fully valid JSON-LD document, therefore the context must include the core @context as part of an array.

"@context": [
            "http://context/ngsi-context.jsonld",
            "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld"
]

ngsi-context.jsonld already contains the core @context (https://github.com/FIWARE/tutorials.Getting-Started/blob/NGSI-LD/data-models/ngsi-context.jsonld), so a context broker will not add it again (it will even fail in 1.8 since the core @context is now protected?).

What is subject for debate, is Accept: application/ld+json when no user context is defined - I currently think that either of these responses are vaild - JSON-LD spec doesn't seem to mandate single element array reduction on @context

Agree. In the ETSI Test Suite, we allow both when only one context entry is expected.

[jason-fox]

ngsi-context.jsonld already contains the core @context (https://github.com/FIWARE/tutorials.Getting-Started/blob/NGSI-LD/data-models/ngsi-context.jsonld), so a context broker will not add it again (it will even fail in 1.8 since the core @context is now protected?).

There should be no issue due to protection since the terms are not defined differently simply repeated. Ideally if I could be certain all brokers worked the same way, and added https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld as necessary, I could remove the defensive duplicate coding:

{
  "@context": [
        "http://context/user-context.jsonld",
        "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld"
    ]
}

And just use user-context.jsonld.