Remove initial context from API spec

[lanthaler]

Since we decided to add a mechanism to clear the active context (in issue #78), we can't rely on the initial context anymore. Instead we should specify that the information currently contained in the initial context has to be hardcoded in a compliant JSON-LD parser.

PROPOSAL: Remove initial context from API spec and define that compliant JSON-LD parsers have to automatically coerce the value of @type to an IRI.

[gkellogg]

I'm worried about throwing out the initial context altogether. We may find other uses for it in the future. This could be addressed by updating #78 to define "clear the active context" as "set the active context to the initial context".

[lanthaler]

Removing it now doesn't prevent us to re-add it later if we really need it. I just think that it would make parsers and the spec simpler.

[msporny]

PROPOSAL: There is an initial context for all JSON-LD processors with one entry - { "@type": "http://www.w3.org/1999/02/22-rdf-syntax-ns#" }. When a "@context" is set to null, the active context is set to the initial context.

[gkellogg]

It is also useful to have the entry {"@graph": {"@type": "@id"}}, which should also exist for @type.

Otherwise, I'm not sure what having @type expand to "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" (I presume that was intended) buys us. It doesn't do anything during expansion, compaction or framing. FromRDF does this selectively based on a property. The only other place it's useful is in toRDF. Indeed, if we had this, then you might consider that @type would be expanded to "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" during expansion, which it is not. And that "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" should be compacted to @type, which is probably the case, but Niklas' use cases indicate that having this explicitly set in a context is probably the way to go.

So, -1 on this proposal. But I would suggest an alternative:

PROPOSAL: There is an initial contet for all JSON-LD processors:

{
  "@type": {"@type": "@id"},
  "@graph": {"@type": "@id"}
 }

[lanthaler]

Which would imply that @type can be overwritten.. something we don't wanna allow.
-1 on this

[gkellogg]

We specifically disallow redefining keyword IDs, so this doesn't really open the door up for that. However, we could allow the following:

{
  "@type": {"@container": "@set"}
}

This shouldn't remove the @type:@id, but would say that when compacting or framing, always place @type in an array. This is probably the default for @graph.

[lanthaler]

Quoting from the current spec:

"If a term is re-defined within a context, all previous rules associated with the previous definition are removed."

So I'm still -1 on this and think it causes much more confusion than necessary without much advantages. Framing should be used to address such use cases IMO.

[lanthaler]

RESOLVED: _If_ JSON-LD has an initial context, it MUST be specified external to the JSON-LD Syntax specification at a well-known location.

[lanthaler]

RESOLVED: Do not support an initial context in JSON-LD 1.0.