In some situations it is important/necessary to include the base direction of a text, alongside its language; see the “Requirements for Language and Direction Metadata in Data Formats” for further details. In practice, in a vanilla JSON, it would require something like:

"title": [ { "value": "Moby Dick", "lang": "en" },
           { "value": "موبي ديك", "lang": "ar"  "dir": "rtl"}
         ]  

(the example comes from that document).

At this moment, I believe the only way you can reasonably express that in JSON-LD is via cheating a bit:

"title": [ { "@value": "Moby Dick", "@language": "en" },
           { "@value": "موبي ديك",  "@language": "ar"  "dir": "rtl"}
         ]  

and making sure that the dir term is not defined in the relevant @context so that, when generating the RDF output, that term is simply ignored. But that also means that there is no round-tripping, that term will disappear after expansion.

The difficulty lies in the RDF layer, in fact; RDF does not have any means (alas!) to express text direction. On the other hand, this missing feature is a general I18N problem whenever JSON-LD is used (there were issues when developing the Web Annotation Model, these issues are popping up in the Web Publication work, etc.).

Here is what I would propose as a non-complete solution

1. Let us introduce a @dir term, alongside @language. This means this term can be used in place of dir above, ie, it is a bona-fide part of a string representation, and would therefore be kept in the compaction/expansion steps, can also be used for framing.
2. In JSON-LD 1.1, @dir is ignored when transforming into RDF. I.e., only the language tag would be used.
3. We may initiate some work in the RDF community to solve this issue. There may be several ways, each of them require the RDF community to chime in
   3.1. Define a mechanism of "parametrized" standard datatypes that represent a (language,direction) pair. One would then get something like[] ex:title "موبي ديك"^^rdf:internationalText(ar,rtl) ;
   3.2. Go for a "generalized" RDF where strings can also appear as subjects (that has been a matter of dispute for a long time...). That would give the possibility to add such attribute to texts like directions
   3.3. Some other mechanisms that I cannot think about
4. In a future JSON-LD 1.* the @dir value can be properly mapped onto an RDF representing the right choices (if such choices are worked out)

Cc: @BigBlueHat @r12a