-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider bidirectional (bidi) tag? #79
Comments
I agree completely. |
This comment was marked as resolved.
This comment was marked as resolved.
This was discussed during the rdf-star meeting on 24 September 2024. View the transcriptBacklog to add additional issuesbacklog: https://github.com/orgs/w3c/projects/20/views/5 <pchampin> https://github.com/orgs/w3c/projects/20/views/6 pchampin: these are the ones "needs discussion" pchampin: we talk about w3c/rdf-concepts#79 <gb> Issue 79 Reconsider bidirectional (bidi) tag? (by termontwouter) [needs discussion] [wr:open] <gkellogg> PROPOSAL: The working group has considered w3c/rdf-concepts#79 and will continue to support initial text direction in RDF Language-Tagged Literals. We will not otherwise consider full bidi. <pchampin> +1 <gkellogg> +1 <ora> +1 <AndyS> +1 <gtw> +1 <Dominik_T> +1 <doerthe> +1 <ktk> +1 <niklasl> +1 <tl> +1 <Tpt> +1 RESOLUTION: The working group has considered w3c/rdf-concepts#79 and will continue to support initial text direction in RDF Language-Tagged Literals. We will not otherwise consider full bidi. <gb> Issue 79 Reconsider bidirectional (bidi) tag? (by termontwouter) [needs discussion] [wr:open] <tl> AndyS thanks! <TallTed> Does anyone have the URL to the recording? <TallTed> pchampin - Note that the minutes at <https://www.w3.org/2024/09/24-rdf-star-minutes.html> do NOT include what was there "yesterday". Also, there's now nothing at <https://www.w3.org/2024/09/23-rdf-star-minutes.html> nor <https://www.w3.org/2024/09/23-rdf-star-irc>. <TallTed> pchampin -- bah, I'm looking at rdf-star for did logs. sorry. TallTed: not sure who started the recording, probably pchampin or ora niklasl: great slides by the way <AndyS> +1 <niklasl> Thank you! I had a lot of great feedback from the group, so I won't take all the credit. :) <gkellogg> Power out in the hotel, so there will be some delay before we start up. <TallTed> i|I will not start a new log at midnight|previous meeting: https://www.w3.org/2024/09/20-rdf-star-minutes.html <TallTed> i|I will not start a new log at midnight|next meeting: https://www.w3.org/2024/09/26-rdf-star-minutes.html <TallTed> i|I will not start a new log at midnight|agenda: https://www.w3.org/events/meetings/f8a5c74c-2bd4-45d4-89e7-9f5c84c6f9e0/ <TallTed> i/I will not start a new log at midnight/previous meeting: https://www.w3.org/2024/09/20-rdf-star-minutes.html <TallTed> i/I will not start a new log at midnight/next meeting: https://www.w3.org/2024/09/26-rdf-star-minutes.html <TallTed> i/I will not start a new log at midnight/agenda: https://www.w3.org/events/meetings/f8a5c74c-2bd4-45d4-89e7-9f5c84c6f9e0/ <pchampin> just so you know, there is a power outage in the TPAC hotel, so the meetings are disrupted <dlehn> 9 of us are on zoom and starting to chat anyway. we're not sure what that agenda should be. <anatoly-scherbakov> gtfierro/reasonable <anatoly-scherbakov> pbonte/roxi <gkellogg_> Power out may go on until 3:00 PDT, or about 3 1/2 hours from now. gkellogg_: oh wow what should we do? <gkellogg_> There's really nothing we can do and we should end the meetings for the day. We may start something up when power is back, but that's probably too late for people in Europe. |
|
I'll rest my case then, but I wonder whether the WG could also divulge what that consideration has involved, i.e. WHY it decided on this despite the points I raised. |
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
LANG
directive 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.
The text was updated successfully, but these errors were encountered: