Re: Language maps and undefined language

All,

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


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

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.

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

Would result in:

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

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? :)

Rob

Issue:
https://github.com/json-ld/json-ld.org/issues/480#issuecomment-294170927



On Fri, Apr 14, 2017 at 7:58 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>



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