Reconsider bidirectional (bidi) tag? #79
Description
I'll apologize in advance for commenting on this now, after it seems to have been already fully decided upon, but I stumbled upon this decision only recently.
I must say I was quite stunned, discovering the addition of base direction tags to RDF 1.2. I have some background in the topic from experimenting with parsers, and I took my time to read through the additional documents/discussions I found regarding the specific decision here, but I find it to be grounded in some strange pro's and con's, and i.m.o. it goes against the very nature of RDF's original design. If you will hear me out, I would like to raise some points that should sufficiently represent my case.
-
RDF aims to be an abstract description language. In the case of literals, the minimal structure of a string plus a datatype annotation allows us to express basically everything. Adding extra structure is theoretically never necessary (language tags themselves included). Any attempt at doing so should therefore cause a very strong knee-jerk reaction.
-
Disregarding the above and adding structure anyway leads to a very slippery slope. We started (unwisely i.m.o.) with doing it for natural languages. Then we discover that there is a problem with the expressiveness of that structure (one we would not have if those languages were treated as any other datatype): so now we add an indication of base direction. But what will we do with the next (natural) language-related characteristic that we need to express? This is not an empty guess: this WG itself even stated that "[t]he problem of setting the base direction for a string is, actually, the tip of the iceberg of internationalization issues around RDF literals." Practices such as this lead to a complex and inflexible structure.
-
An alternative solution, using the characteristic expressive power of RDF's typed literals, has already been proposed and discussed: using the datatypes of the i18n namespace (cf. JSON-LD). The advantages are obvious: datatypes can be composed for any number of characteristics of a literal; they are not limited to a language, script or text direction. Later discovered important characteristics can easily be added, either as new standalone terms, or built on existing terms using query parameters.
-
One argument against the above solution seems to be that SPARQL’s
LANGdirective would then lose its purpose. I am flabergasted that this strawman has actually been taken into account. This same WG discusses SPARQL 1.2, and can thus easily introduce a parallel change there, either abolishing the redundant directive, or redefining it as sugar for a datatype-check. -
Another counterargument was that this would not allow us to express direction without language tag. Ironically, the proposed new syntax does not allow that either! Moreover, it is an invalid point, since the current absence of such terms in the i18n namespace does not prevent us from introducing them.
If you took the time to read until here, I am grateful, and cannot do much more to make my case, but pray that something that can be expressed with existing mechanisms will not complicate an otherwise elegant language. I'm curious to hear your thoughts.