Create additional assertions via contexts

[azaroth42]

(This is a meta-issue)

Many existing JSON structures use simple "short cut" properties when there is only a single piece of information known about an intermediate resource. For example, if only the name of the author of a book is known then a creator property with a literal value is shorthand for a longer assertion chain of that the book was created by some actor that has the given name.

Thus:

{
  "type": "Book",
  "creator": "J.R.R. Tolkien"
}

Could be expanded to:

{
  "type": "Book",
  "created_by": {
    "type": "Actor",
    "label": "J.R.R. Tolkien"
  }
}

This could be added to the context for creator:

"creator": {
  "@type": "@nest", 
  "@values": {"@type": "Actor", "@property": "label", "@id": "created_by"}
}

Or similar.

[azaroth42]

I'm a strong 👎 on this sort of thing. I believe that contexts should not do data transformation, only assert a mapping between JSON keys and the graph structure that already exists. This is a reductio argument against #7 and #15.

[iherman]

We do have exactly this issue in the Web Publication Manifest and the draft includes a separate "canonical manifest" section that defines a number of transformation steps like this one.

However, even with this example around, I am wary of such feature for JSON-LD 1.1. We should not use the context feature for data transformation. It may open pandora's box. We may want to look at this issue in general at some point, but that may have to be treated separately and probably needs a longer incubator period. For example, even if we did it, we should may want to have an explicitly different mechanism defined for this, not part of @context but a separate @transform patterns to make it more explicit and not make @context even more complex that it is. It may also touch on RDF graph transformations, ie, not necessarily bound to a particular serialization.

At this moment, I am 👎 on this...

[BigBlueHat]

FWIW, Google's Structured Data Testing Tool (which only supports one vocabulary: Schema.org) makes some undeclared assumptions (based on that single vocabulary) which amount to this sort of coercion.

You can see a more complete description in this comment over at the WPUB repo, but essentially, there's an unexpressed "default" Thing class into which string values get coerced:

{"@context": "http://schema.org/", "@type": "Book",
 "publisher": "asdf"}

becomes

{"@context": "http://schema.org/", "@type": "Book",
 "publisher": {"@type": "Thing", "name": "asdf"}}

This does feel like it moves the needle from vocabulary into ontology.

[azaroth42]

On the call of 2018-09-07, the WG resolved to close this issue won't fix, with the same rationale as #7. The use cases should be discussed in the CG.