I am trying to design a message protocol. The message protocol uses a message document (aggregate document) with a generic data property whose values can be arbitrary "payload documents" (embedded documents).
Aggregate Documents:
The aggregate document declares a @context which is an external context loaded from remote. It maps
terms of the aggregate document onto a vocabulary using a @vocab declaration. In the given use case it wil map technical terms from the message protocol onto a message protocol vocabulary.
Embedded Documents
Embedded documents are embedded into aggregate documents. Every embedded document declares its own embedded context using @context. In the given use case payloads could be business documents mapping their terms onto a business vocabulary (unknown to the message protocol).
Example (Message Protocol)
{
"@context": "http://api.foo-mail.org/remote/context/",
"@type": "Message",
"name": "Sample Message/Mail",
"data": {
"@context": {
"@vocab": "http://xmlns.com/foaf/0.1/"
},
"hint": "Embedded (arbitrary) document attached to a Message with an embedded context."
"name": "Attribute should map to 'http://xmlns.com/foaf/0.1/name' from embedded context's default vocabulary."
}
}
The problem
JSON-LD Playground indicates name in the embedded document would be mapped onto the vocabulary declared within the aggregate document's remote context and get the same URI than name in the aggregate document. Expectation would be that name in the embedded document would be prefixed with the @vocab URI of the default vocabulary from the embedded context.
As we see, schema.org's remote context declares a @vocab default vocabulary URI http://schema.org/ (which is the equivalent to the message protocol vocabulary in the initial use case).
On JSON-LD Playground the reproduction example then produces (among others) an RDF triple
So I'd expect that any term in the embedded data document would be mapped onto the default @vocab``http://xmlns.com/foaf/0.1 of the embedded document's context.
If this is a misinterpretation of the spec, can you tell why the spec authors may think a remote context's vocabulary (which in case of schema.org wasn't even under my control) should be able to override a document's own embedded vocabulary mappings?
Use case
I am trying to design a message protocol. The message protocol uses a message document (aggregate document) with a generic
data
property whose values can be arbitrary "payload documents" (embedded documents).Aggregate Documents: The aggregate document declares a
@context
which is an external context loaded from remote. It maps terms of the aggregate document onto a vocabulary using a@vocab
declaration. In the given use case it wil map technical terms from the message protocol onto a message protocol vocabulary.Embedded Documents Embedded documents are embedded into aggregate documents. Every embedded document declares its own embedded context using
@context
. In the given use case payloads could be business documents mapping their terms onto a business vocabulary (unknown to the message protocol).Example (Message Protocol)
The problem
JSON-LD Playground indicates
name
in the embedded document would be mapped onto the vocabulary declared within the aggregate document's remote context and get the same URI thanname
in the aggregate document. Expectation would be thatname
in the embedded document would be prefixed with the@vocab
URI of the default vocabulary from the embedded context.Reproduction
On JSON-LD Playground we can reproduce the behavior using http://schema.org as the remote context:
Example (Reproduction)
Remote context loaded from http://schema.org/ (after redirects):
As we see, schema.org's remote context declares a
@vocab
default vocabulary URI http://schema.org/ (which is the equivalent to the message protocol vocabulary in the initial use case).On JSON-LD Playground the reproduction example then produces (among others) an RDF triple
Reading Section 4.2 Step 5.8) in JSON-LD 1.1 Processing Algorithms and APIs I would expect a result...
So I'd expect that any term in the embedded data document would be mapped onto the default
@vocab``http://xmlns.com/foaf/0.1
of the embedded document's context.If this is a misinterpretation of the spec, can you tell why the spec authors may think a remote context's vocabulary (which in case of schema.org wasn't even under my control) should be able to override a document's own embedded vocabulary mappings?