Allow @id: null to decouple a term from @vocab

[lanthaler]

Currently there's no way to say that a JSON property shouldn't expand to a full IRI if @vocab was set:

{
  "@context": {
    "@vocab": "http://example.org/vocab#",
    "date": { "@id": null }
  },
  "@id": "example1",
  "date": "test"
}

date should not expand to http://example.org/vocab#date here.

This came up in the 2012-10-16 telecon

[msporny]

While I understand that this feature is being proposed for complete-ness, I don't think we should add the feature to this version of JSON-LD. We haven't had an implementer ask for it. @vocab is a sledgehammer and has a few down-sides - it applying to everything is one of those downsides. If author's don't want that to happen, they shouldn't use @vocab. My biggest concern is the added complexity to JSON-LD for something that seems (to me) like a fairly narrow corner-case. It's one more thing that authors have to look for in contexts... "Okay, vocab is active.... now I need to scan the context to see which items that @vocab doesn't apply to..."

-1 for this feature.

[lanthaler]

Agree, -1 from me as well.

[niklasl]

That would make it impossible to use e.g. proprietary data (such as the attached "rev" object our service requires to expose reverse relations) in combination with @vocab. You still have to scan the context to see which items @vocab doesn't apply to, since it doesn't override other terms.

[lanthaler]

That's true, but how would you interpret something like this then:

{
  "@context": [
    {
      "@vocab": "http://example.org/vocab#"
    },
    {
      "date": { "@id": "http://example.com/someOtherVocab/date" }
    },
    {
      "date": { "@id": null }
    }
  ],
  "@id": "example1",
  "date": "test"
}

What if you set the whole term to null, not just it's id: "date": null.

[lanthaler]

I just pushed a test for this but forgot to reference it. Here's the commit: b5cf284

[niklasl]

I would expect that any term whose @id is explicitly null (or as a shorthand is set to null) is unbound. Is "resetting" terms to "rebind" them to @vocab using null really more compelling? It doesn't seem very readable to merge contexts like that. In your example, I'd rather recommend:

"date": { "@id": "date" }

to achieve that (or rather just pick the terms you need and don't do any redefinitions at all). As said, you still have to scan the context to see which terms @vocab does or doesn't apply to. If the context uses @vocab, any other term there is special in some way. I don't see how an explicitly nulled term (to be used as a comment/annotation) is more out of place just because @vocab is used.

In my case I use a plain rev term to hold a map of reverse relations (it is used in an API built upon ElasticSearch, requiring plain terms). Since we forbid application-specific keywords (like @rev), I cannot set @id to @rev, right? If we reserved something like @comment I suppose I could use that.

[lanthaler]

If the context uses @vocab, any other term there is special in some way.

Isn't that the purpose of @vocab? :-)

I don't see how an explicitly nulled term (to be used as a comment/annotation) is more out of place just because @vocab is used.

Currently a nulled term is simply removed from the active context and @vocab isn't touched which yields to the current behavior. Actually your argument is just as convincing as Manu's.. a developer has to scan the context anyway to see what's going on. Summed up I would be fine either way.

In my case I use a plain rev term to hold a map of reverse relations (it is used in an API built upon ElasticSearch, requiring plain terms). Since we forbid application-specific keywords (like @Rev), I cannot set @id to @Rev, right?

We do not forbid application-specific keywords but discourage from using them for forward-compatibility reasons. What do you mean by setting @id to @Rev?

[lanthaler]

I'm not sure what I should think about this issue. There are good arguments for both sides.. So let's try to see what others think:

PROPOSAL 1: Allow a term to be mapped to null (either directly or by setting @id to null). This mapping is stored in the active context and also overwrites a @vocab mapping meaning that the term does not expand to an IRI and will thus be dropped when expanding.

PROPOSAL 2: If a term is mapped to null (either directly or by setting @id to null) remove its definition from the active context. This means that when a @vocab mapping exists, the term is expanded using the @vocab IRI in expansion and will thus not be dropped.

[msporny]

PROPOSAL 1: +0.5
PROPOSAL 2: +0.4

I'm concerned that, whatever we do here, it'll cause confusion.

[lanthaler]

Btw., proposal 2 is what we currently do

[gkellogg]

I'm with @manu on this. No strong preference, but I can see some advantage to PROPOSAL 1

[lanthaler]

RESOLVED: Allow a term to be mapped to null (either directly or by setting @id to null). This mapping is stored in the active context and also overwrites a @vocab mapping meaning that the term does not expand to an IRI and will thus be dropped when expanding.

[lanthaler]

Neither the grammar section in the syntax spec, nor the context processing algorithm in the API spec have been updated. Perhaps also the compaction algorithm needs to be updated.

[msporny]

Added this feature to the grammar section in commit 9cb2f6e.
Added this feature to the Context Processing algorithm in commit a8a4488.
Added this feature to the Expansion algorithm in commit bf05737.

@lanthaler I think those changes cover everything required for this feature. Can you double-check, if all changes are in we should report back to the list and close this issue 24 hours after that.

[lanthaler]

The syntax spec as well as the API spec have been updated to allow the explicit decoupling of a term from @vocab. Unless I hear objections, I will therefore proceed and close this issue in 24 hours.