json-ld.org | JSON for Linked Data | JSON Processing library

According to Dan Brickley (Google employee with responsibility for Schema.org) these issues will be addressed or documented for the new validator:

Thanks - noted and acknowledged. The tool is not opensource (it is a view provided by Google's structured data validation infrastructure). I will make sure these issues are addressed or documented before we link the new validator more prominently from Schema.org.

https://github.com/schemaorg/schemaorg/issues/2921#issuecomment-879817283

You can't really do this in JSON-LD, or really in RDF in general. This document describes two entities each with a set of properties and assets that each knows the other. The relationship is between entities, and not about specific properties of those entities.

You could make the email address, itself, an entity, and then claim some relationship to it. For example, schema.org has a PropertyValueSpecification, which is can have an @id, and therefore could be referenced, but that is not how I would choose to model it.

JSON-LD-star is a proposed specification for describing the properties of relationships themselves (a variation on RDF-star), so you could create the relationship _:n1 :email "james@007.uk" as an entity, but this doesn't really get to the indirection you describe. Still, it could look something like the following:

Jay is correct that the knowledge comes from the @context. This can be specified in a couple of ways:

• Inline, using an object value for @context (or an array, which includes an object),

• By directly retrieving a context from the URL specified (e.g., https://json-ld.org/contexts/person.jsonld),

• By having the server do context-negotiation on the request, as an HTTP request includes an Accept header preferring JSON-LD (see Interpreting JSON as JSON-LD) such as the following:

From https://www.w3.org/TR/json-ld11/#context-definitions:

"A context definition MUST be a map whose keys MUST be either terms, compact IRIs, IRIs, or one of the keywords @base, @import, @language, @propagate, @protected, @type, @version, or @vocab. "

So @context really doesn't know nything about nested information as you have it with