Gregg Kellogg

This was considered in #76 and rejected as being out of scope. It certainly can be reconsidered in the future, as it is an often featured request. The solution for...

New in JSON-LD 1.1 was the ability to have document-relative vocabulary terms, by allowing `@vocab` to take a relative IRI, which is resolved against the base IRI via concatentation Example...

> Probably #387 needs to be an Erratum with appropriate content to describe this change, unless done elsewhere. Added in https://github.com/w3c/json-ld-syntax/issues/387#issuecomment-1144136010, which will automatically cause this to show up in...

I came to a similar conclusion about how to do this, but the question remains: what use case is this solving. I don't see how it allows, say, a WoT...

IMO, sealing a context for which you have no control can lead to problems, as it may change out from underneath you in the future and make data which used...

To be consistent with other deferred issues, I've reopened this and marked with the defer-future-version label.

As you likely know, `@reverse` creates a reverse property relationships, so mapping "entries" to both `skos:inScheme` and `skos:hasTopConcept` creates a problem, if they're used in the same entity. Of course,...

So, in theory, the expansion case would work, where "entries" would map to two reversed IRIs. But, to be symmetric "@id" would be allowed an array of IRIs, as well,...

As there is no technical issue with the spec's use of IRI, I don't see how an ErratumRaised is appropriate here. There have been some long-standing discussions about replacing IRI...

Note that [GeoJSON-LD](http://geojson.org/geojson-ld/) notes problems with JSON-LD 1.0 for representing coordinates which are defined using lists of lists, which is unsupported in JSON-LD 1.0. JSON-LD 1.1 [does support lists of...