extend language maps to support base direction

[pchampin]

currently, language maps in JSON-LD allow to create literals with a language tag, but not with a base direction, which is not good from an i18n point of view.
If you want to to express the title of a book about JSON-LD both in English and Arabic, you need the following (expanded) JSON-LD:

{
    "http://schema.org/title": [
        { "@value": "JSON-LD and Linked Data", "@language": "en", "@direction": "ltr" }
        { "@value": "JSON-LD والبيانات المرتبطة", "@language": "ar", "@direction": "rtl" }
    ]
}

but you can't get this result with a language map.

A workaround is possible by defining different properties with language maps, one for ltr titles, and one for rtl titles (see example in the playground). But that requires contexts designers to provision it.

An alternative would be to extend the expansion algorithm for language maps, to accept a special format in their keys containing both language tag and optionally a base direction. All we need is an encoding which is not ambiguous with valid language tags. A possible separator would be --, which is what Turtle uses. Another possible separator is a space, but it is less YAML-friendly (and actually looks odd, spaces in keys are not usual).

Example:

{
  "@context": {
    "titles": {
      "@id": "http://schema.org/title",
      "@container": "@language",
      "@context": {
        "@direction": "ltr"
      }
    }
  },
  "titles": {
    "en": "JSON-LD and Linked Data",
    "ar--rtl": "JSON-LD والبيانات المرتبطة"
  }
}

[anatoly-scherbakov]

Sometimes people do use spaces in YAML keys, which looks wrong but is correct syntactically.

I wonder if language and direction can be resolvable. Maybe ar#rtl can be resolvable against an ontology?

[pchampin]

Sometimes people do use spaces in YAML keys, which looks wrong but is correct syntactically.

I stand corrected, then. But then it would look even more odd in YAML than it does in JSON...

I wonder if language and direction can be resolvable. Maybe ar#rtl can be resolvable against an ontology?

There could be dereferenceable IRIs for language codes and based directions, but that's an orthogonal issue.