Language maps on literals with no language don't play well together

[gkellogg]

As described in this email, mixing literals having language, with those not having a language in a language map creates an odd structure when compacting:

If a string is associated with a property defined as a languageMap, but
does not have a language associated with it, it creates two keys in the
JSON ... the langStrings go in one, and the non-langStrings in another.
This is unintuitive and exposes some of the weirdest weirdness of RDF
(langStrings) to unsuspecting JSON developers.

A proposal to discuss:

If compaction would result in an attempt to add a string without an
associated language into a LanguageMap, then the processor SHOULD assign
the undefined language code UND as the key in the array.

Thus,
_:x rdfs:label "Fish"@en, "Poisson"@fr, "51234" .

Would result in:

{
"@id": "_:x",
"label": {"en": "Fish", "fr": "Poisson", "UND": "51234"}
}

Rather than the current compaction result:

{
"@id": "_:x",
"label": {"en": "Fish", "fr": "Poisson"},
"rdfs:label": "51234"
}

Notes:

• PHP does not support "" as a key in a dictionary, and thus UND as the key
• This does not propose an inverse expansion rule, in case someone has an
  explicit @und langString [seems unlikely], where it should not become a
  regular xsd:string

References:

digitalbazaar/jsonld.js#151
IIIF/api#755

[gkellogg]

Jakob Voß notes that "und" actually means "Unknown language", and "zxx" may be more appropriate, which means "No linguistic content/Not applicable".

Perhaps this (or something similar) would be a way to address this. When trying to use a language-mapped term with a literal with no language, the language tag "zxx" is used as a key. {“@value”: “foo”, “@language”: “zxx”} should probably also work and perhaps just expand to {“@value”: “foo”}.

cc/ @azaroth42

[azaroth42]

Thanks for making the issue!

UND is "Undetermined" ... which, to me, captures both "q2341234"@UND where there is no linguistic content, and "fish"@UND where there is, but the language isn't known.

As such, as a fallback for when there isn't a language specified, it makes more sense to me to use UND than the more explicit ZXX which would be incorrect for the "fish" case.

[azaroth42]

And, with all due respect to Jakob ... the I18N group agrees:

https://www.w3.org/International/questions/qa-no-language

[workergnome]

Just to clarify—this only applies if the property is explicitly marked as a languageMap in the context, correct? - David Newbury ----------------------------------- p. (773) 547-2272 e. david.newbury@gmail.com

…

On Tue, Apr 11, 2017 at 8:33 PM, Rob Sanderson ***@***.***> wrote: And, with all due respect to Jakob ... the I18N group agrees: https://www.w3.org/International/questions/qa-no-language — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACG6Jk8mriU5r7w9-ISM_NjPx_R9eZTks5rvBvlgaJpZM4M6zWj> .

[gkellogg]

@workergnome Yes, but we need to consider the results of expanding and removing the concept of a language-map, or compacting something that didn't originally have a language map.

But, we could decide that for JSON-LD, the use of a language-map term is sufficient indicate that literal values, without an explicit @type, are considered to have an unknown language (und), in most cases, this is probably the case.

[gkellogg]

Jakob Voß writes:

"" is a legal object key in JSON and PHP just happens to be one programming languages with full support of JSON, so why design JSON-LD with focus on a particular choice of implementation in PHP? The language can deal with "" keys in JSON data pretty well:

<?php
$json = '{"":1}';
$data = json_decode($json, true);
echo $data[""]; # prints '1'
?>

If you prefer PHP objects over PHP arrays, the "" can internally be replaces by another special value but that's a personal choice of implementation and out of the scope of JSON-LD.

Using "" for non-language strings looks like the cleanest and most obvious solution to me.

[dlongley]

Cross-posting from the mailing list in response to Jakob Voß's comments:

I don't remember all of the implementation trouble related to the use of empty strings in PHP, but I do remember it being more complex than is being hinted at here. I'm pretty sure that you can't use PHP arrays because you lose the ability to easily distinguish between arrays and objects, which is a requirement for proper implementation.

In any event, how difficult it is to implement a syntax's processing rules in common programming languages should absolutely be a factor in related design decisions -- otherwise adoption could be harmed in a significant way.

It would indeed be nice if there were no issue here, but, unfortunately, I'm not yet convinced that's true. My memory is that the two PHP implementers agreed that this was a pain point worth avoiding. If we can
get a new implementer to step forward (or PRs to the existing implementations) that clearly demonstrate that this problem can be fully avoided without serious detriment to performance or significantly increased implementation complexity, then I'll agree that we should no longer consider it when making future design decisions.

[dlongley]

Related: https://bugs.php.net/bug.php?id=46600

It seems that this limitation in PHP may have finally been dealt with in June of last year -- we'll need to figure out which version of PHP has the fix (and how prevalent), if true.

[dlongley]

PHP 7.1 (the latest version) now supports empty string properties in objects:

http://php.net/manual/en/migration71.incompatible.php

Decoding an empty key now results in an empty property name, rather than empty as a property name.

[azaroth42]

Fantastic ... back to the list for a revised proposal...