Re: Language maps and undefined language


Thanks to Dave's great sleuthing on the github issue, he found this recent

So when the decision about empty keys was made it was valid, but that has
been fixed in PHP.

So I retract my original proposal and instead propose:

If compaction would result in an attempt to add a string without an
associated language into a LanguageMap, then the processor MUST assign the
empty string as the key in the array. Expansion of the empty string is the
inverse, resulting in a string value with no language.

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

Would result in:

  "@id": "_:x",
  "label": {"en": "Fish", "fr": "Poisson", "": "text in unidentified

Rather than the current compaction result:

  "@id": "_:x",
  "label": {"en": "Fish", "fr": "Poisson"},
  "rdfs:label": "text in unidentified language"

New thoughts on the new proposal? :)



On Fri, Apr 14, 2017 at 7:58 AM, Dave Longley <>

> On 04/13/2017 06:32 AM, Jakob Voß wrote:
>> Hi again,
>> Rob wrote:
>> Note that we cannot use "", as noted, because PHP does not support
>>>> empty string as the key of a dictionary... and thus we fallback to
>>>> using "und”.
>> "" 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.
> 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.
> --
> Dave Longley
> Digital Bazaar, Inc.

Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

Received on Friday, 14 April 2017 16:03:53 UTC