The core definition

The current definition for langString is in section 3.3 of the RDF 1.1 document [[rdf11-concepts]]. It is based upon assigning a language tag, using [[bcp47]], to a string. It is somewhat of an odd case in the RDF 1.1 model insofar as it has, in contrast to all other data types in RDF, an additional structure: the lexical form comprises a string and the additional (language) tag (in contrast to other datatypes consisting of a single string, albeit possibly with a restricted content). The value space of the datatype is also defined as a set of tuples consisting of the literal string and the language tag. This peculiarity means that langString literals have to be treated separately by all RDF implementations.

Extending this core datatype would mean to keep this unique structure and to add a third element for a base direction to the tuple both in the lexical and the value spaces. This base direction tag MUST have the value of ltr, rtl, with the semantics as defined for the dir attribute in [[html]].

A separate document contains the first draft for the necessary changes in the relevant section of RDF 1.1 [[rdf11-concepts]].

Note that there are use cases when a string SHOULD have a base direction but has no language; an example is an ISBN number which, if not specified as being ltr, may be displayed erroneously in a rtl context. This also means that langString may be considered to be a misnomer, although it may be retained for historical reasons.

Serializations

The serializations of a renewed langString SHOULD be defined in such way that the presence of either the language tag or base direction tag is OPTIONAL (but not both, i.e., one MUST be present). This is important to ensure that current RDF datasets would remain valid.

                            <rdf:Description >
                                <ex:example xml:lang="he" rdf:dir="rtl">פעילות הבינאום, W3C</ex:example>
                                <ex:isbn rdf:dir="ltr">978-2-290-16543-0</ex:isbn>
                            </rdf:Description>
                        

                            [] ex:example "פעילות הבינאום, W3C"@he^rtl ;
                               ex:isbn "978-2-290-16543-0"@^ltr .
                        

                            "ex:example" : {
                                "@value" : "פעילות הבינאום, W3C",
                                "@language" : "he",
                                "@direction" : "rtl"
                            },
                            "ex:isbn" : {
                                "@value" : "978-2-290-16543-0",
                                "@direction" : "ltr"
                            }
                        

Pros and Cons

Extending the langString can be considered as the “ideal” solution: it takes care of what could be considered (from an internationalization point of view) as a missing feature (some would call it a bug) in the original RDF specification. It also fits very well the current specification. Its effects on the RDF Semantics [[rdf11-mt]] is only editorial: the tuples for langString for literals in general, and D-entailment in particular, should simply include a new tag. Indeed, the RDF Semantics does not make use of the semantics of [[bcp47]] values, nor should it use the semantics of the base direction tag.

A major problem with the approach is that, because it touches the “core” or RDF, such a change would affect a large number of recommendations that all rely on that core: SPARQL, SHACL, RDFa, R2RML, etc. That means that if the core RDF specification is updated, all other documents may have to be updated at the same time, which becomes a significant endeavor. Similarly, deployment is also a major problem: because language tagged literals are treated separately in RDF, all implementations (Jena, RDFLib, Sesame, various triple stores, Turtle and RDF/XML parsers and serializers, etc.) MUST be updated. That may take a long time, and it may not be easy to convince the community to do so.

Core definition

As a reminder, defining a new datatype means (per the RDF specification):

• Define a lexical space.
• Define a value space.
• Define a lexical-to-value mapping.
• Assign a unique URL to the new datatype.

There may be different possibilities to define a new datatype (or datatypes). These are defined in the following two sections

Serializations

Because this is a new datatype, strictly speaking there is no need for a new serialization; all concrete syntaxes have a way to express literals with a datatype. E.g., in Turtle, the literal would have the form of

                        [] ex:example "פעילות הבינאום, W3C@he^rtl"^^rdf:LocalizableString ;
                           ex:isbn "978-2-290-16543-0@^ltr"^^rdf:LocalizableString .
                    

or, respectively

                        [] ex:example "פעילות הבינאום, W3C"^^i18n:he_rtl ;
                           ex:isbn "978-2-290-16543-0"^^i18n:_ltr
                    

and in JSON-LD

                        "ex:example" : {
                            "@value" : "פעילות הבינאום, W3C@he^rtl",
                            "@datatype" : "rdf:LocalizableString"
                        }
                        "ex:isbn" : {
                            "@value": "978-2-290-16543-0@^rtl",
                            "@datatype" : "rdf:LocalizableString"
                        }
                    

or, respectively

                        "ex:example" : {
                            "@value" : "פעילות הבינאום, W3C",
                            "@datatype" : "i18n:he_rtl"
                        }
                        "ex:isbn" : {
                            "@value": "978-2-290-16543-0",
                            "@datatype" : "18n:_ltr"
                        }
                    

However, newer versions of the the serialization syntaxes MAY introduce the syntactic facilities to express this new datatype by adopting the serialization formats as shown for the langString extension case; these would be considered as syntactic sugar to generate these datatypes. E.g.,

                        "ex:example" : {
                            "@value" : "פעילות הבינאום, W3C"
                            "@language" : "he",
                            "@direction" : "rtl"
                        }
                    

could be considered as valid JSON-LD, generating a LocalizableString, or i18n:*, respectively, when mapped upon RDF. An advantage of introducing such a shorthand in JSON-LD is that vanilla JSON may adopt the same pattern which can be used in general regardless (see also the definition of Localizable in [[string-meta]].)

(Care should be taken of the fact that adopting such extra syntactic facilities means that the same localizable string could be expressed in two different ways. While this may not create too much problems in most cases, it may require some extra considerations if and when a canonical RDF format is defined.)

Pros and Cons

The major advantage of these approaches is that it is mostly transparent to current RDF deployments, and thus affects only application layers that do display the literal values for humans. It also works for parsers “out of the box”, unless new serialization versions are defined.

The major disadvantage is that it is never a good idea to introduce yet another micro-syntax into a specification; it is the source of confusion and possible errors. (This can be mitigated by introducing new syntactic sugars.) Also, applications that want to make use of base direction values would have to handle some sort of a duality, insofar as the data may include both langString and LocalizableString (or, respectively, i18n:*) language strings.

(See also some further issues.)

Pros and Cons

The major advantage of this approach is that it combines the ideal solution of taking care of an RDF “bug” while ensuring a somewhat smoother deployment.

A disadvantage is that it creates a special case in several concrete syntaxes (e.g. Turtle), where the rdf:LocalizableString or i18:XX_YY family of IRIs are used as "magic" terms, and end up being interpreted as a different IRI (namely rdf:langString). Another disadvantage is that there has to be a very careful consideration when the datatypes are deprecated, rescinded, etc., i.e., it will need a careful monitoring of the RDF ecosystem evolution.

Core definition

The following terms are defined in RDF:

• rdf:CompoundLiteral: is a class representing a compound literal.
• rdf:language: an RDF property. The range of the property is an rdfs:Literal, whose value must be a well-formed [[bcp47]] tag. The domain of the property is rdf:CompoundLiteral.
• rdf:direction: an RDF property. The range of the property must be an rdfs:Literal, whose value must be either "ltr" or "rtl". The domain of the property is rdf:CompoundLiteral.

Semantically, the following triples represent a compound literal, whose language and base direction are specified:

                        _:a rdf:type rdf:CompoundLiteral .
                        _:a rdf:value "פעילות הבינאום, W3C" .
                        _:a rdf:language "he" . 
                        _:a rdf:direction "rtl" .
                    

The (blank) node _:a stands for the literal, whose language is Hebrew, and whose direction is right-to-left.

The rdf: namespace has been used in the definition for the sake of simplicity; it is a separate decision whether that, or another namespace should be used.

                            _:a rdf:type rdf:CompoundLiteral .
                            _:a rdf:value "פעילות הבינאום, W3C" .
                            _:a rdf:language i18n:lang#he . 
                            _:a rdf:direction i18n:dir#rtl .
                        

Serializations

(The serialization of the RDF like variant is left as an exercise for the reader.)

                                [] ex:example [
                                    rdf:value "פעילות הבינאום, W3C" ;
                                    rdf:language "he" ; 
                                    rdf:direction "rtl" ;
                                ] .
                        

                            "ex:example" : {
                                "@value" : "פעילות הבינאום, W3C"
                                "@language" : "he",
                                "@direction" : "rtl"
                            }
                        

Pros and Cons

The major advantage of this approach is that it is fully transparent to current RDF deployments, and affects only application layers that do display the literal values for humans. It also work for parsers “out of the box”. As an extra bonus (as mentioned “Language Tagged Strings” discussion) it may actually be easier to query such compound literals via, say, SPARQL than using the current RDF approach.

The obvious disadvantage is that it duplicates a mechanism for expressing strings with a language tag only: one can use the core langString datatype or the compound literals. The relationship between the two forms should be specified.

Core definition

Add -d-ltr and -d-rtl to the [[bcp47]] language tags. I.e., a full language tag could look like lang-d-dir, where lang is a valid [[bcp47]] language tag as of today, and dir MUST have the value of ltr or rtl with the semantics as defined for the dir attribute in [[html]]. See also [[d-langtag]].

Serializations

In terms of serializations, this change could be completely transparent for RDF. I.e., the examples used before would become, in Turle:

                            [] ex:example "פעילות הבינאום, W3C"@he-d-rtl .
                        

and in JSON-LD:

                        "ex:example" : {
                            "@value" : "פעילות הבינאום, W3C",
                            "@language" : "he-d-rtl"
                        }
                    

Pros and Cons

Beyond the general issues described below, this approach has the additional problem that it requires a formal extension of the current [[bcp47]] standard. The first reaction of that community (see, e.g., the relevant email thread on the IETF mailing list) were certainly not in favor…

Core definition

Define the -x-d-ltr and -x-d-rtl private-use language subtags. I.e., the language tag could look like lang-x-d-dir, where lang is a valid [[bcp47]] language tag, and dir MUST have the value of ltr, rtl with the semantics as defined for the dir attribute in [[html]]. Per definition this usage of this private-use tag is restricted to a specific family of specifications (at this moment one could restrict it to RDF, OWL, SPARQL, SKOS, etc., their various serializations, plus possibly JSON and CBOR).

Serializations

In terms of serializations, this change could be completely transparent for RDF. I.e., the examples used before would become, in Turtle:

                            [] ex:example "פעילות הבינאום, W3C"@he-x-d-rtl .
                        

and in JSON-LD:

                            "ex:example" : {
                                "@value" : "פעילות הבינאום, W3C",
                                "@language" : "he-x-d-rtl"
                            }
                        

Pros and Cons

See the section below for a general discussion.

Pros and Cons

Mark Davis, in his github comment, formalized the approach further on what a user agent may have to do. However, further discussions revealed that the algorithmic approach is significantly more complicated (see a separate wiki page) and is at odd with the current deployment and usage of language tags.

See the section below for a general discussion.