[Bug]: `@prefix` not consistently set to true

[jeswr]

In particular for the two following tests, the first one correctly adds the '@prefix': true but the second test errors because '@prefix': true is not set.

it('should parse a globally protected string term ending in gen-delim with identical override', () => {
        return expect(parser.parse([
          {
            '@protected': true,
            'foo': 'http://example/foo#',
          },
          {
            '@protected': true,
            'foo': 'http://example/foo#',
          },
        ], { processingMode: 1.1 })).resolves.toEqual(new JsonLdContextNormalized({
          foo: {
            '@id': 'http://example/foo#',
            '@prefix': true,
            '@protected': true,
          },
        }));
      });

      it('should parse a globally protected string term ending in gen-delim', () => {
        return expect(parser.parse([
          {
            '@protected': true,
            'foo': 'http://example/foo#',
          },
        ], { processingMode: 1.1 })).resolves.toEqual(new JsonLdContextNormalized({
          foo: {
            '@id': 'http://example/foo#',
            '@prefix': true,
            '@protected': true,
          },
        }));
      });

I think this is the root cause of the the broken test I was trying to resolve in #112 (comment).

Is it necessary to have '@prefix': true set in each case?

[rubensworks]

If I remember correctly, the context parser will try to add '@prefix': true to all prefixes, even if they were just implicit via gen-dilim characters. But I'm not 100% certain on that.

[jeswr]

The logic for adding it is part of validateKeywordRedefinitions which is only called when there is a parent context.

So the question here really is, do we want to alter this behavior so that '@prefix': true will also be added in the second case where there is no parent context.

[rubensworks]

The details of prefix handling in JSON-LD 1.1 are a bit too fuzzy in my mind to give a good answer to this. But I do remember some big differences between the handling of the compact/expanded form.

As long as all the unit and spec tests still pass after changing this, I'm certainly open to such a change.