Lint complains of redefinition when re-using term with context

[absoludity]

Simplest reproducible example (it may have other errors after simplifying): AShape defines the position term (which in turn defines the x and y terms). CBox tries to re-use the position term without any modification:

{
  "type": ["VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "shapes": "https://example.com/imaginary/shapes/",
      "@protected": true,
      "@version": 1.1,
      "AShape": {
        "@protected": true,
        "@id": "shapes:Shape",
        "@context": {
          "position": {
            "@protected": true,
            "@id": "shapes:position",
            "@context": {
              "x": "xsd:string",
              "y": "xsd:string"
            }
          }
        }
      },
      "CBox": {
        "@protected": true,
        "@id": "shapes:Box",
        "@context": {
          "position": "shapes:position"
        }
      }
    }
  ],
  "credentialSubject": {
    "type": ["CBox", "AShape"]
  }
}

If the type is both ["CBox", "AShape"] as it is for the credentialSubject property above, then lint complains with the following:

$ jsonld lint -l test-file.jsonld 
jsonld.SyntaxError: Invalid JSON-LD syntax; tried to redefine a protected term.
    at api.createTermDefinition (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/context.js:988:13)
    at api.process (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/context.js:399:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async api.expand (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/expand.js:238:23)
    at async _expandObject (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/expand.js:926:25)
    at async api.expand (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/expand.js:251:3)
    at async jsonld.expand (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/jsonld/lib/jsonld.js:322:18)
    at async Command.lint (file:///home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/bin/jsonld.js:304:5)
    at async Command.parseAsync (/home/michael/.nvm/versions/node/v20.13.1/lib/node_modules/jsonld-cli/node_modules/commander/lib/command.js:936:5)
Error: {
  name: 'jsonld.SyntaxError',
  details: {
    code: 'protected term redefinition',
    context: { position: 'shapes:position' },
    term: 'position'
  }
}

When debugging, I can see it's failing when comparing the properties of the two terms which should be equal, but instead, it finds the lengths different at:

jsonld.js/lib/context.js

Lines 1589 to 1591 in 7165607

	if(k1s.length !== k2s.length) {
	return false;
	}

If I print the two terms there with

    console.log(`not equal: ${JSON.stringify(x1)} and ${JSON.stringify(x2)}`);

I see that the two differ because one has an @context key, the other doesn't:

not equal: {"reverse":false,"_termHasColon":false,"@id":"https://example.com/imaginary/shapes/position","_prefix":false,"protected":true,"@context":{"x":"xsd:string","y":"xsd:string"}} and {"reverse":false,"_termHasColon":false,"@id":"https://example.com/imaginary/shapes/position","_prefix":false,"protected":true}

which looks like the context isn't included when aliasing (or shouldn't be included in the comparison - not sure which).

[davidlehn]

The errors are because the complete term definitions are different while protected. The term ids are the same, but the comparison is on the entire definition.

If you want to experiment a bit more, you can remove the protected flags and add a position property with x/y sub properties. You'll note this also fails! When processing, it will evaluate the types in lexicographic order, define the AShape position, with scoped context, then overwrites it with the CBox definition without the scoped context, then it doesn't know what the x/y properties are. If you were to rename them to A-CBox and B-AShape, it would then "work" due to the reversed order. But in more complex situations you might then drop or redefine properties in a different way.

I'm guessing when using both those types at once you wanted to effectively deep merge their definitions? I'm not sure if this syntax supports that at the moment for constructs like this.

The parts you're logging are internal structures and used for comparison purposes. Semantically equivalent contexts parts can be written in different ways so comparison needs to be done on a processed version.

[absoludity]

If you were to rename them to A-CBox and B-AShape, it would then "work" due to the reversed order.

That's funny - while reducing my actual example to a simplest working example, I found that the error didn't occur when I had just Box and Shape - hence renaming to AShape and CBox... now it's obvious why :P

I'm guessing when using both those types at once you wanted to effectively deep merge their definitions? I'm not sure if this syntax supports that at the moment for constructs like this.

Nothing that complicated - it's probably the lack of depth in my understand of jsonld yet, but all I'm trying to do is ensure that both AShape and CBox have a "position" without having to redefine it. The actual doc that I have appears to assume it can just use a reference to it, as I've done in this simplified example.

But based on what you've said, and testing with the example, the only way to have the same type for both position's is to redefine it identically? That is, the following passes jsonld lint as expected, but I can't avoid the duplication? (I mean, with the example, I don't think I need to define the term twice anyway right, but the system I'm using is generating these based on a model defn that also outputs json-schema etc.):

{
  "type": ["VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "shapes": "https://example.com/imaginary/shapes/",
      "@protected": true,
      "@version": 1.1,
      "AShape": {
        "@protected": true,
        "@id": "shapes:Shape",
        "@context": {
          "position": {
            "@protected": true,
            "@id": "shapes:position",
            "@context": {
              "x": "xsd:string",
              "y": "xsd:string"
            }
          }
        }
      },
      "CBox": {
        "@protected": true,
        "@id": "shapes:Box",
        "@context": {
          "position": {
            "@id": "shapes:position",
            "@context": {
              "x": "xsd:string",
              "y": "xsd:string"
            }
          }
        }
      }
    }
  ],
  "credentialSubject": {
    "type": ["CBox", "AShape"]
  }
}

[davidlehn]

I did figure that A and C where probably for ordering, but in case not, added the other prefixes.

The common pattern I've been seeing if data might use a type of Box, Shape, or both, and wants protected contexts, then you need duplication. Maybe I'm forgetting a nice trick around that.

The issue here, and with some other similarly reasonable use cases, is that use cases have eclipsed the basic features provided and people are looking for more complete programming language features. It's not hard to imagine subclasses, directives to merge from another local common definition, or a more comprehensive import/export system. Such features need to either be added to JSON-LD specs or some sort of pre-preprocessor/generator.

There is a trick here, but it's evil. I think you could put the shared definitions in another context file and use @import to merge them in to each definition. That's not really ideal use of that feature, and something better should be provided some day. For now some sort of auto-generation of the context with duplication might be the best idea.