JSON-LD response does not conform to JSON-LD 1.1 spec

[sjvanrossum]

Describe the bug
JSON-LD API responses specify @context's @version property as "@context": "1.1", but the spec for JSON-LD 1.1 states that this field must be a number, mandating that it be returned as "@version": 1.1. In addition to being malformed JSON-LD 1.1 this currently breaks compatibility with digitalbazaar/pyld and digitalbazaar/jsonld.js.

To Reproduce
https://api.weather.gov/stations?state=AL&limit=1
https://api.weather.gov/stations/C1231
https://api.weather.gov/zones/forecast/ALZ266
https://api.weather.gov/zones/county/ALC003
https://api.weather.gov/zones/fire/ALZ266
https://api.weather.gov/stations/C1231/observations/latest

Expected behavior
"If the context definition has an @version key, its value MUST be a number with the value 1.1." (JSON-LD 1.1, § 9.15 Context Definitions)
"The unaliased @version keyword MAY be used as a key in a context definition. Its value MUST be a number with the value 1.1. This keyword is described further in § 9.15 Context Definitions." (JSON-LD 1.1, § 9.16 Keywords)

Expected behavior would be that either "@version": 1.1 is sent or @version is not sent at all, since it is optional.

Environment
Python requests, Chrome XHR, browser response.

Chrome console (replace URL, likely prints string upon completion):

fetch('https://api.weather.gov/path/to/resource', {
    method: 'GET',
    headers: {
      'Accept': 'application/ld+json'
    }
  })
  .then(res => res.json())
  .then(json => console.log(typeof json['@context']['@version']))

[StephenClouse]

We will look into fixing this.

However, it should be noted that our current intent is to deprecate JSON-LD support at a later date. We would encourage using the GeoJSON output and disregarding the JSON-LD components.

[sjvanrossum]

Thank you! I'll have a look at how I can incorporate GeoJSON instead of JSON-LD.