Closed azaroth42 closed 5 years ago
Terms expand to IRIs, so it's not possible to define an alias for "en-gb" which is anything other than an IRI. The exception is for aliases to keywords, so @none
works.
The algorithm does try to expand keys for all maps, including language maps, which is why @none
aliasing works, but we're limited by how terms can be defined.
Yup, agreed that we can't do it now (because I tried, and got the error :) ) but is it valuable enough to add it?
I can sympathize with the argument that "en-gb" is not usable as a JS property, but I think that a general aliasing mechanism would add too much complexity.
What about creating a special case for language maps, replacing all underscores in the keys by dashes (if I'm correct, BCP 47 tags can not contain underscores)?
This does add complexity to the overall spec (but much smaller than a general alias mechanism), and it does create a backward incompatibility (but only for cases which are somehow invalid anyway). Also, we this would create round-tripping problems...
Is it really worth it?
Note also that it is always possible (although not as convenient) to use an index map:
{
"@context": {
"label": { "@id": "http://example.org/label", "@container": "@index" }
},
"label": {
"en_gb": {
"@value": "hello",
"@language": "en-gb"
}
}
}
This issue was discussed in a meeting.
RESOLVED: Close syntax #158 won’t fix, too complicated for the value gained
It's possible to alias
@none
tonone
in a scoped context of a language map, but should it also be possible to alias other language keys? For example, ifen-gb
was aliased toen_gb
, then it would be usable as a property in javascript.