language-maps don't allow separate base direction

[gkellogg]

Language Maps allow strings to be indexed by their language-tag, which provides no means of changing the default or term-specific @direction.

A hypothetical change would be to allow value objects without @type or @language as the value of a language map.

{
  "@context": {
    "@version": 1.1,
    "ex:lm": {"@container": "@language"}
  },
  "ex:lm": {
    "en": "HTML and CSS: Design and Build Websites",
    "ar-EG": "HTML و CSS: تصميم و إنشاء مواقع الويب"
  }
}

[iherman]

This issue was discussed in a meeting.

• RESOLVED: the WG is happy to merge #276, but leaves it to the editors whether they do it now or after the API changes is also in a PR
• ACTION: create issue on values of language maps not including <code>@direction</code> (Gregg Kellogg)
  View the transcript

  Benjamin Young: See Issue Syntax#1§1
  Benjamin Young: See Pending PR on @direction
  Benjamin Young: no much to discuss; just to make sure everyone is aware of the PR
  Gregg Kellogg: I will only merge it when the tests pass;
  … currently working on my implementation;
  … maybe only merge when we have an API PR.
  … The syntax PR does not address the ability for a language map to contain value objects with @value and @direction.
  … Currently they only support strings.
  … So there is no way to override the direction in a language map.
  Ivan Herman: I think we can defer this to a future version.
  Benjamin Young: is there an issue for this already?
  Ivan Herman: raise an issue, so we can make it clear if we decide to postpone it.
  Action #3: create issue on values of language maps not including @direction (Gregg Kellogg)
  Dave Longley: the syntax doc proposes 2 or 3 ways to represent this in RDF in order to roundtrip.
  … We should only recommend one.
  … We would have to maintain them for many years.
  … My preferred option would be to drop the @direction by default,
  … with an option to serialize it in the way we think is the best for future RDF.
  … That would force people to update their RDF lib,
  … but that what we were expecting if a dedicated WG had been created.
  Ivan Herman: half of your wishes are already fulfilled:
  … by default, the @direction is dropped.
  … We picked two options for roundtripping:
  … * the i18n family of datatypes,
  … * the “compound literal” approach (not a very good name).
  … At the meeting in Fukuoka, even around the table,
  … there was no clear consensus about which one was the best option.
  … The idea is to let the community decide which one they want to use.
  Dave Longley: Why not a 3rd option where we add a property to a literal?
  Ivan Herman: because this is not valid RDF.
  … The failure to create a WG shows that the RDF community is not willing to change the core of RDF.
  … The advantage of the two proposed approaches is that they work with the deployed RDF infrastructure,
  … even though they require some application-level knowledge to be used.
  Dave Longley: What I’m hearing is “more technical depts, and no interop”
  … If this is something that people need, and we introduce a hack to get it work,
  … people will adopt the hack.
  Ivan Herman: you can call it a hack, but this is the only thing that people seem ready to accept.
  … Trying to force RDF to change is a bigger hack in my opinion.
  Dave Longley: JSON-LD 1.0 did influence the RDF WG at the time, to extend RDF.
  Ivan Herman: this is the big difference; there was an RDF WG at the time.
  … There is none at the moment, nor can I foresee one in the near future.
  Dave Longley: sometimes, standard follow implementations, rather than the opposite.
  Pierre-Antoine Champin: I’d argue that the proposed solutions are not so hacky from and RDF point of view
  … I prefer the datatype solution
  … but none of them seem a scandal to me
  … if there was an RDF WG working on this, they would consider one of these as the future standard
  Ivan Herman: +1 to pchampin
  Gregg Kellogg: I agree, these solutions are reasonable from the point of view of RDF.
  … Also, the default option is to drop direction.
  … The majority of data will not use direction, and not produce RDF differently than today.
  Dave Longley: dropping it is a good default;
  … but I expect Digital Bazaar being force to keep it in some way.
  … For example, in VC, when the graph is signed, we need to keep the whole information.
  Gregg Kellogg: from a digital signature point of view,
  … I would not consider the direction to be relevant.
  … Would two values differing only by direction be really different?
  Dave Longley: this is scary; that could be turned into a terrible vulnerability.
  Ivan Herman: I would like a resolution to allow Greg to merge the direction PR;
  … this has lingered for too long.
  Proposed resolution: the WG is happy to merge #276, but leaves it to the editors whether they do it now or after the API changes is also in a PR (Ivan Herman)
  Ivan Herman: +1
  Gregg Kellogg: +1
  Harold Solbrig: +1
  Pierre-Antoine Champin: +1
  Benjamin Young: +1
  Tim Cole: +1
  Dave Longley: +0
  Ruben Taelman: +1
  Resolution #2: the WG is happy to merge #276, but leaves it to the editors whether they do it now or after the API changes is also in a PR
  

[iherman]

There seems to be only very few usages for this (it is only useful if one has a literal with a direction that needs to be added to a language map). We are also close to CR, and this change would require some non-trivial changes (including the tests). I would therefore propose to label this as a postponed issue, to come back for a possible future release.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer use of direction for text in language maps to a future version
  View the transcript

  Language-maps and @direction
  Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/280
  Rob Sanderson: With our introduction with @direction we can’t then use the direction in a language map because you can’t put the @value object as the value of the language map. We could change language maps to allow that but it’s very very late in the day and it doesn’t seem like there’s a big need. No one is clamoring for this particular functionality.
  … Any further clarification?
  Ivan Herman: No.
  Gregg Kellogg: It’s pretty clear.
  Benjamin Young: Just a quick note that I’ve never seen direction in a key – this language map format is semi common, even outside of JSON-LD, but never seen it.
  … +1 to defer.
  Gregg Kellogg: What you might imagine would be a combination of language and direction that would be similar for what we do with the i18n datatype. Where we separate language and direction with an underscore. I can imagine some future version that might do that. That might be more useful than allowing values that were value objects.
  … There’s no demonstrated need to do this, so it’s reasonable for us to hold off until a need is demonstrated.
  Proposed resolution: Defer use of direction for text in language maps to a future version (Rob Sanderson)
  Dave Longley: +1
  Ivan Herman: +1
  Rob Sanderson: +1
  Pierre-Antoine Champin: +1
  Gregg Kellogg: +1
  Benjamin Young: +1
  Resolution #2: Defer use of direction for text in language maps to a future version