Add section on cross-syntax language and base direction expression.

[msporny]

This PR adds a section on cross-syntax language and base direction expression to the string-meta specification. The purpose of this section is to advise specification designers on the proper way to express language and base direction in a way that is useful to developers using one or more syntaxes like JSON-LD, JSON, and CBOR.

[msporny]

Review requested by @aphillips @r12a @dlongley @burnburn @chaals @iherman @gkellogg and @pchampin.

[gkellogg]

Example 2 sets the language and direction of title and other properties, which would be odd in a normal context; this is where you would more likely use either a top-level @language, or a language map. I think the use case shows the advantage of combining direction with a BCP47 extension (or whatever is ultimately agreed upon), so that it can be represented in language maps.

For example:

{
    "@context": ["https://example.com/myapp/v1",
      {
        "title": {"@container": "@language"},
        "authors": {"@container": "@language"},
        "publisher": {"@container": "@language"}
      }
    ],
    "identifier": "978-111887164-5",
    "title": {
      "ar-x-d-rtl": "HTML و CSS: تصميم و  إنشاء مواقع الويب"
    },
    "authors": {
      "en-x-dir-ltr": "Jon Duckett"
    },
    "pubDate": "2008-01-01",
    "publisher": {
      "ar-x-dir-rtl":  "مكتبة"
    },
    "coverImage": "https://example.com/images/html_and_css_cover.jpg",
    // etc.
}

But, without going there, using a separate @direction is reasonable, and it may be a top-level context property as well, similar to @language. Semantically, it would apply only to strings that are interpreted using @language.

[iherman]

I think that, before accepting this PR, there should be a discussion with the JSON-LD WG. The text is anticipating decisions that are currently not (yet?) taken...

[iherman]

Readable version of Manu's proposal: https://raw.githack.com/msporny/string-meta/rdf-dir/index.html
Diff: https://tinyurl.com/y55ftj3t

[iherman]

Much as I like JSON-LD :-), I have reservations the way 2.4 is formulated (but whose trace are also there in the original document at the end of 2.2 recommending JSON-LD). My reading of the section is that the advise is to use JSON-LD 1.x (ie, a version that also has a direction keyword) to express what we need. While it is fine to express the string values using the

{ "value": "...", "lang": "..", "dir": "..."}

idiom but, I believe, requiring the users to include a full-blown @context to express all this will not fly. Vanilla JSON (or CBOR) users will just run away screaming.

I believe the right approach is to define a formalism that is JSON-LD compatible but without any reference to a context file at first. We can then make it clear that those specifications that do want to use JSON-LD can easily do so by either providing a context in the JSON text (and we can go into what that context should look like) or provide the JSON-LD via HTTP. Motto is to 'hide' the -LD part unless people really do want to use linked data.

[iherman]

B.t.w., if all this gets accepted, providing a short @context file on https://www.w3.org/ns/XYZ.jsonld might be a good idea, so that authors could just refer to it.

[msporny]

I believe the right approach is to define a formalism that is JSON-LD compatible but without any reference to a context file at first.

That's fine, we can do some sort of "progressive enhancement" approach. So, the progressive enhancement steps are:

1. If you are JSON/CBOR and want to express this sort of thing, use { "value": "...", "lang": "..", "dir": "..."}.
2. If you want to use JSON-LD, use 1.1 and the aliasing/language/direction mechanism.

I can make those changes when I get a chance to do another edit cycle.

[gkellogg]

I agree with @iherman that there’s still so much happening with this elsewhere that I think it’s premature to settle on any one of them in this document.