Revisit empty string as term

[gkellogg]

JSON-LD has a restriction that terms must not be the empty string

From JSON-LD Syntax 6.1:

Furthermore, the term MUST NOT be an empty string ("") as not all programming languages are able to handle empty JSON keys.

IIRC, this was added due to an issue in an earlier version of PHP, and I suspect it is no longer an issue. Furthermore, the use of empty prefixes is common in other RDF syntaxes, so allowing it here for 1.1 documents would be reasonable, if tooling supports it.

As evidence, consider this stackoverflow question.

Also, note that while the syntax document makes such a normative statement, the API algorithms don't call this out as an error condition.

Original issue Revisit empty string as term #584

[azaroth42]

Do we have a use case for this? The language case was solved with @none, is there any other situation when this would add value?

[iherman]

Coming from turtle, the usage, that then allows predicates like :name is pretty natural (and widely used in turtle I believe).

However... I wonder if this is something that comes naturally to a JSON user and whether it is, in fact, more twisting her mind rather than be helpful... which may backfire conveying the idea of JSON-LD being overly complex:-(

(Honestly: I have never thought of using an empty string as a key in JavaScript or Python. I did not even realize this was possible...)

[dlongley]

I think we'd want some input from Markus (@lanthaler) on this one -- as he'd have to deal with it in his PHP implementation. I don't know if we'd be updating our PHP implementation any time soon ... nor do I know how widely it is used. I suppose if this change is accepted we might find out! 😄

[BigBlueHat]

Coming from turtle, the usage, that then allows predicates like :name is pretty natural (and widely used in turtle I believe).

How important is it to match the Turtle stylistically in JSON-LD? Seems the risk (support in PHP < 7.1, confusingness, etc) may not worth the reward?

[lanthaler]

I don't understand what value this would add. On the other hand, I expect that such a feature would add a considerable amount of confusion. JSON-LD has @vocab which lets you achieve pretty much the same as Turtle does:

@prefix : <http://xmlns.com/foaf/0.1/> .

#me :name "Markus"

{
  "@context" {
    "@vocab": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "#me",
  "name": "Markus"
}

Note how name doesn't have a prefix.

[gkellogg]

The motivation for allowing empty strings as keys in JSON-LD would simply be for completeness; IIRC, it was not allowed in 1.0 because of issues in PHP, otherwise, why create an exception. JSON, itself, defines objects have having string keys referencing JSON values, with no restriction that the string be non-empty.

 object = begin-object [ member *( value-separator member ) ]
          end-object
 member = string name-separator value

That said, there's really not a compelling use case for allowing this now, and I'm 👍 for closing this issue as wontfix.

[azaroth42]

👍 to close won't fix as there's no use case we're actually solving here, and the confusion of mapping empty string to some value would be never-ending.

{
"@context": {
  "": "@id"
  },
  "": "http://example.org/foo"
}

[iherman]

👍 to won't fix

[ajs6f]

👍 to won't fix

[davidlehn]

Just to document my thoughts in case this is ever revisited, here are two esoteric use cases:

Obfuscated JSON-LD:
This is not really a serious use case, but could be fun to allow empty terms to mean something.

Term Compression:
It could be an interesting experiment to try term compression by adding common terms to a context with short names. For instance, if you had a large dataset such as:

{
  "@context": ...,
  "things": [
    {
      "@id": "urn:ex:1",
      "a-rather-long-term-name": { ... }
    },
    ... a million more items ...
  ]
}

One could construct a context to "compress" this data:

{
  "a": "a-rather-long-term-name",
  ...
}

A compact phase would result in:

  ...
  "things": [
    {
      "@id": "urn:ex:1",
      "a": { ... }
    },
    ... a million more items ...
  ]

And later you could re-compact with some other context to recreate whatever structure and term names you need. I'm unsure if this is actually useful. Maybe it could be with huge datasets to save memory or space, I'm unsure? Probably better to just use an alternate JSON serialization and/or regular compression tools. But if it was useful, then having the empty term "" available would allow one term per context scope to compress very well! There's certainly a tradeoff with the possible confusion of empty strings. If anyone happens to stumble upon this issue and has a real use case like this, perhaps this could be revisited.

[gkellogg]

Resolved to Close.

[azaroth42]

WG resolved to close this issue won't fix, as there is no use case (beyond minified or obfuscated context declarations) and allowing it will generate confusion rather than add value.