Error reported when setting "@language": null in a value object

[jasnell]

According to http://www.w3.org/TR/json-ld/#string-internationalization, the following should be valid:

{
  "@context": ["http://asjsonld.mybluemix.net", {"@language": "en"}],
  "@id": "urn:example:1",
  "displayName": {
    "@value": "foo",
    "@language": null
  }
}

jsonld.js returns an error, however (as evidenced on the playground: http://tinyurl.com/o25sr3y)

{
   "name": "jsonld.CompactError", 
  "message": "Could not expand input before compaction.", 
  "details": { 
    "cause": { 
      "name": "jsonld.SyntaxError", 
      "message": "Invalid JSON-LD syntax; language map values must be strings.", 
      "details": { 
        "code": "invalid language map value",
        "languageMap": { "@value": "foo", "@language": null } 
      } 
    } 
  } 
}

[dlongley]

So, displayName is defined as a language map container in the context. This means that displayName's value must be an object whose keys represent language codes (see: Language Maps). For example:

{
  "@context": ["http://asjsonld.mybluemix.net", {"@language": "en"}],
  "@id": "urn:example:1",
  "displayName": {
    "en": "foo"
  }
}

So you shouldn't be using keywords in there, but, this has exposed an inconsistency between the JSON-LD syntax spec and the JSON-LD API spec that I've created a new issue to resolve.

[jasnell]

This also highlights a current deficiency (IMHO) in the JSON-LD syntax spec. Specifically, the following cases should be treated as roughly equivalent:

{
  "@context": { "f:foo": { "@container": "@language" } },
  "f:foo": "foo"
}

{
  "@context": { "@language": null , "f:foo": { "@container": "@language" } },
  "f:foo": "foo"
}

{
  "@context": {"f:foo": { "@container": "@language" } },
  "f:foo": {
    "@value": "foo",
    "@language": null
  }
}

{
  "@context": {"f:foo": { "@container": "@language" } },
  "f:foo": {
    "@value": "foo"
  }
}

In other words, given that "f:foo" is defined as "@container": "@language", the literal value "foo" ought to be handled as the value object {"@value": "foo", "@language": null}.

[davidlehn]

The purpose of using language containers is to provide syntax sugar for mapping language codes to values by means of object keys and values. It is probably not possible to distinguish a real language container vs some other object. What is the use case for wanting to treat these as equivalent? By "roughly" do you mean exactly?

[jasnell]

For Activity Streams 2.0, I want to ability to allow certain fields like "displayName" to take one of three basic forms:

A.

{
  "displayName": "foo"
}

B.

{
  "displayName": {
    "en": "foo", 
    "fr": "bar"
  }
}

C.

{
  "@context": {"@language": "en"},
  "displayName": "foo"
}

With A. being equivalent to:

{
  "displayName": [
    {
      "@value": "foo", 
      "@language": null
    }
  ]
}

And B. being equivalent to:

{
  "displayName": [
    {
      "@value": "foo", 
      "@language": "en"
    }, 
    {
      "@value": "bar",
      "@language": "fr"
    }
  ]
}

And C. being equivalent to:

{
  "displayName": [
    {
      "@value": "foo", 
      "@language": "en"
    }
  ]
}

The goal is to allow producers of AS 2.0 documents to use the simplest form (literal string) when there is either a default language context or the language context is undefined, but allow a language map to optionally be used when multiple language-tagged strings are required.

[jasnell]

It ought to be fairly trivial to distinguish a value object from a language map given the "@value" and "@language" keywords have specific meaning in JSON-LD and are not valid language tags.

[dlongley]

@jasnell - it doesn't work that way to ensure that the term takes on a regular structure (ie: you can assume it will always be a map or it will always be an @value container or whatever). Could you use separate terms and let developers and authors pick the one of their choice? For example, "displayName", "displayNameByLanguage" (for the map version), etc.?

[jasnell]

Would rather not but we can, however, require that AS2 serializers always use the map form but allow consumers to read in the literal string form (the expansion algorithm actually handles it quite well).

[dlongley]

We should add a test demonstrating that this passes now and then close this issue.

[dlongley]

Closing as addressed per comment from 5 years ago.