Introducing @dir ?

[iherman]

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

[gkellogg]

In general, I think this is a good idea; having a mechanism in place that could map to a future RDF standard for representing text direction is forward looking.

Having keywords which are ignored in the RDF transformation is not unprecedented: @index is also ignored.

There are also implications for term definitions and term selection when compacting:

1. @dir might appear in a term definition, and be used to match values with the appropriate @dir.
2. @dir could appear at the top level of a context, to set the default text direction.

Basically, most everything that is done with @language could be done with @dir (dir maps?)

[dlongley]

Just a quick bikeshedding note -- should we decide to support this feature, I think it would be better to use something longer that is more specific than @dir, e.g. @direction (better in that it is less ambiguous but still not great, IMO ... direction of what?).

[iherman]

@dlongley "direction" is the usual term in the i18n circles (for "base writing direction"); I think that, paired with @language, it is fine.

[iherman]

@gkellogg I was wondering about @direction maps, but I would have difficulties to come up with a use case for this. I would not want to add it to the spec just because we can do it...

[azaroth42]

I'm nervous of introducing something that doesn't round trip through RDF. Either RDF is our conceptual model, or it isn't. This would open the door for also adding @type at the same time as @language, despite that language tagged strings in RDF 1.1 have an explicit data type.

Not -1, but I think we need to consider the slipperiness of the slope we're starting to slide down.

[BigBlueHat]

Echoing @azaroth42 I'd prefer (if such things are even conceivable) that we iterate RDF to include text direction encoding.

Additionally, this doesn't address BiDi strings...nor can it (afaict):
https://www.w3.org/International/wiki/Html-bidi-isolation
https://www.w3.org/International/questions/qa-bidi-controls

[iherman]

@azaroth42, @BigBlueHat :

1. The problem with RDF roundtripping makes me uneasy, too. However, the problem I see is that there is, at this moment, no WG/group/whatever that could authoritatively solve the RDF aspect of the problem, although that has been banging on our door for a while. I do not see any reality in setting up a WG on this. Our only avenue would be to raise the issue on the SW IG, and have some ad-hoc solution getting some level of consensus (although that can take a long time), but that would not have any normative status. (Probably the quickest solution would be to define a datatype, as I sketched in the original comment.)
2. @BigBlueHat, it is perfectly true that this does not cover the detailed bidi control. But that would be way more difficult because it would lead to a reconstruction of what HTML does and would also require to impose a particular syntax in the literal itself. In some sense, using the rdf:HTML datatype may be the best solution but the comment in the string-meta document (but also this) is very relevant to the practical difficulties of this approach in practice.

The reason why I raised this issue, in spite of sharing the same reservations that both of you have, is purely pragmatic: communities face this issue and we simply do not have a satisfactory solution. And, I presume, the "perfect is an enemy of the good" principle may apply...