No base direction metadata

[aphillips]

(citing Thing but globally in the document)
https://w3c.github.io/wot-thing-description/#thing
https://w3c.github.io/wot-thing-description/#titles-descriptions-serialization-json

Natural language string values, notably title and description (and their language map friends titles and descriptions) do not provide for base direction metadata.

As defined in 5.3.1.1 Thing, the base text direction used to display human-readable metadata can either be estimated using heuristics such as the first-strong rule or inferred from language information. In TD documents the default language is defined by a value assigned to @language in the @context, and this, along with a script subtag if necessary, can be used to determine a base text direction. However, when interpreting human-readable text, each human-readable string value MUST be processed independently. In other words, a TD Processor cannot carry forward changes in direction from one string to another, or infer direction for one string from another one elsewhere in the TD.

Note Strings on the Web [STRING-META] suggests both strong-first and language-based inferencing as means to determine the base text direction. Given that the Thing Description format is based on JSON-LD 1.1 [json-ld11], which currently lacks explicit direction metadata, these approaches are currently considered appropriate at the time of this publication. However, if JSON-LD 1.1 adopts support for explicit base direction metadata as recommended by [STRING-META], the Thing Description format should be updated to take advantage of that feature.

JSON LD 1.1 has the i18n namespace and can be used to define a compound literal for strings with both language and direction metadata.

https://www.w3.org/TR/json-ld/#the-i18n-namespace
https://www.w3.org/TR/json-ld/#the-rdf-compoundliteral-class-and-the-rdf-language-and-rdf-direction-properties

[egekorkan]

I suggest to add a section like JSON-LD did (or refer to it) like https://www.w3.org/TR/json-ld/#base-direction

Would this be enough? (it feels correct but not enough maybe?)

[egekorkan]

I have forgotten to write it down properly but in the call of 02.03 we have agreed to put this information in the spec, thus the PR needed label