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

Closed
lanthaler opened this Issue Oct 16, 2012 · 15 comments

Comments

Projects
None yet
4 participants
Member

lanthaler commented Oct 16, 2012

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

Owner

msporny commented Oct 21, 2012

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.

Member

lanthaler commented Oct 22, 2012

Agree, -1 from me as well.

Member

niklasl commented Oct 22, 2012

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.

Member

lanthaler commented Oct 22, 2012

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.

Member

lanthaler commented Oct 22, 2012

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

Member

niklasl commented Oct 22, 2012

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.

Member

lanthaler commented Oct 22, 2012

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?

Member

lanthaler commented Nov 7, 2012

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.

Owner

msporny commented Nov 7, 2012

PROPOSAL 1: +0.5
PROPOSAL 2: +0.4

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

Member

lanthaler commented Nov 7, 2012

Btw., proposal 2 is what we currently do

Owner

gkellogg commented Nov 7, 2012

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

Member

lanthaler commented Nov 13, 2012

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.

msporny closed this in ebdd010 Dec 2, 2012

Member

lanthaler commented Dec 4, 2012

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.

lanthaler reopened this Dec 4, 2012

Owner

msporny commented Dec 22, 2012

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 lanthaler added a commit that referenced this issue Dec 27, 2012

@lanthaler lanthaler Remove redundant statement from Expansion algorithm
This addresses #165.
936b448
Member

lanthaler commented Dec 27, 2012

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.

lanthaler closed this Dec 28, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment