Support for RDF 1.2 initial text direction

[afs]

Add support for RDF 1.2 text direction

Initial text direction is a feature in RDF 1.2.
https://www.w3.org/TR/rdf12-concepts/#section-text-direction

It is a new facet of language string literals:
https://www.w3.org/TR/rdf12-concepts/#section-Graph-Literal

Turtle syntax:
https://www.w3.org/TR/rdf12-turtle/#grammar-production-LANG_DIR

A text direction can be ltr or rtl (case insensitive).

[HolgerKnublauch]

Does anyone have a use case and suggested syntax for such a constraint?

I am aware that RDF 1.2 is introducing this feature but that doesn't automatically mean that SHACL needs to declare a constraint component for it.

[gkellogg]

Initial text direction is an important part of the W3C internationalization effort, and could come up in horizontal review. Documents such as https://www.w3.org/TR/string-meta/ address some uses, but the lack of support does not adequately address the needs of locales which use different direction, particularly when scripts can be mixed.

Not worth re-litigating the need for supporting this in every WG in which it comes up, but as a core component of literal resources, it represents an important axis for representing literals and carries the same weight as datatyps and language.

[HolgerKnublauch]

I am trying to get control over the remaining Core issues so that the WG can move to the next stage. It is helpful to have requirements and background, but I believe in order to make this practical, someone should suggest the name for a new constraint parameter and an example use case so that one of the editors can finalize it. I have zero experience with this feature and I don't think it needs to be up to the editors to do all the background research.

[afs]

There is a Unicode algorithm that chooses the text direction - the first "strong character" - https://www.w3.org/TR/string-meta/#issues has a brief discussion.

The algorithm is imperfect e.g. a hashtag (Latin script) and an Arabic tweet.

Identifiers (i.e. "keys") can be fragile as well.

The Unicode algorithm also means an application has to analyse the string contents.

While langtag script subtags do give a direction, script subtags are not commonly used. Arabic, and Hebrew, both have latin scripts.

"cat" is "قطّ"@ar and "qit"@ar. "قطّ"@ar--rtl and "qit"@ar--ltr.

SPARQL adds functions LANGDIR, hasLANGDIR, STRLANGDIR.

The functions LANG and hasLANG are extended to work on both rdf:langString and rdf:dirLangString.
i.e. LANG and LANGDIR are treated as component accessors.

[HolgerKnublauch]

Ok, so if there are SPARQL functions such as hasLANGDIR, those would be lifted into node expressions, and everything could be represented using sh:expression? (I know this story sounds like a broken record)

[afs]

We need a principle for what goes where.

Nick gave a useful one in the 2025-06-02 meeting that if it is an feature RDF 1.2, something ought to be in SHACL Core (i.e. "static" - no node expressions). That might get extended with node expressions.

sh:languageIn and sh:uniqueLang need reviewing.

(What's the general outline of a shape for validating SKOS pref/alt labels?)

[HolgerKnublauch]

Marking this as postponed as we are beyond the planned work cycle for SHACL Core. We can revisit this if there is renewed time and interest.