Allow @type for @none in Language Maps

[BigBlueHat]

Multilingual values in JSON-LD is currently best handled by using the rdf:HTML datatype on a value in JSON-LD. However, that currently cannot be used alongside language maps.

The following example is cribbed from https://github.com/w3c/wpub/issues/299 + the addition of @none:

{
  "@context": {
    "occupation": { "@id": "ex:occupation", "@container": "@language" },
    "description": "ex:description"
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža",
    "@none": "<span lang=en>Ninja in japanese: <span lang=jp>忍者</span>"
  }
}

The output n-quads looks like:

_:b0 <ex:occupation> "<span lang=en>Ninja in japanese: <span lang=jp>忍者</span>" .
_:b0 <ex:occupation> "Nindža"@cs .
_:b0 <ex:occupation> "Ninja"@en .
_:b0 <ex:occupation> "忍者"@ja .

If the content is in fact multilingual, then that first triple should look like:

_:b0 <ex:occupation> "<span lang=en>Ninja in japanese: <span lang=jp>忍者</span>" ^^rdf:HTML.

The first alternative I tried to express this was:

{
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža",
    "@none": {
      "@value": "<span lang=en>Ninja in japanese: <span lang=jp>忍者</span>",
      "@type": "rdf:HTML"
    }
  }
}

Which currently throws:

jsonld.SyntaxError: Invalid JSON-LD syntax; language map values must be strings.

Given that rdf:HTML is the current recommendation for multilingual content in RDF, JSON, YAML, etc, I'd propose we find ways to express rdf:HTML (and perhaps future datatypes) as the type of @none would found in a language map--at the @context level and/or within the data.

Cheers!
🎩

[pchampin]

This could be achieved by aliasing the occupation property

{
  "@context": {
    "occupation": { "@id": "ex:occupation", "@container": "@language" },
    "occupationHTML": { "@id": "ex:occupation", "@type": "rdf:HTML" },
    "description": "ex:description"
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  },
  "occupationHTML": "<span lang=en>Ninja in japanese: <span lang=jp>忍者</span>"
}

[iherman]

This issue was discussed in a meeting.

• RESOLVED: close #91 as wrong solution for the right problem

View the transcript

Benjamin Young: #91
Benjamin Young: Idea with 91 is that there is no way to fall back to HTML, which international has suggested is best way to deal with language issues
Gregg Kellogg: issue is to allow non-string values, for which a value object without type might be one option, and opening that door allows almost anything
… that ruins the normality, and not sure it helps the use case
… seems you’d be more likely to use either all language tags or all html literals
Ivan Herman: i think you should either close or defer - this issue did come up in pub wg
… their concern is a bit convoluted to talk about
… when I wrote it down, I got a private message that they didn’t really like this solution (right after TPAC)
… pinged them 2 days ago.
… the result may be that in JSON and JSON-LD this issue can not be done perfectly, and we should be cognizant of perfect is the enemy of the good
… title element seems one place where this could come up, but title doesn’t allow html text
… we should avoid being more catholic than the pope
Adam Soroka: mostly agreeing with what’s been said
… a pattern of string, string, string, complex stuff, string, string is not good
Adam Soroka: +1
David Newbury: +1
Adam Soroka: goes against trying to keep json-ld in line with expectations
Pierre-Antoine Champin: I agree that this is a strange use case, but regardless i posted a solution that works in dev playground
… having 2 distinct properties, one accept a string, one a language map
Benjamin Young: similar to Annotation and Social WG for some of their specs
Pierre-Antoine Champin: a little more cumbersome
Proposed resolution: close #91 as wrong solution for the right problem (Benjamin Young)
Adam Soroka: the kind of thing pchampin is offering seems a good option, can we open an issue to generate examples
Ivan Herman: +1
Benjamin Young: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +1
Adam Soroka: this is a pattern that could be confusing, we should offer best practices
Tim Cole: +1
David Newbury: +1
Adam Soroka: +1
Resolution #4: close #91 as wrong solution for the right problem