Fixed bug where @vocab terms with identical context conflict in context resolution

[tsdrone]

Threaded a active_property "path" array through compaction, expansion and context processing such that it is added to the cache-key (normalized context representation) for storing and retrieving processed contexts from the cache.

To reproduce the bug compact with a context containing 2 property terms of @type: @vocab with identical property-scoped '@context' declarations.

[dlongley]

@davidlehn,

Could you look into this? We should get a test case up based on the description -- and see if we have the same problem with jsonld.js. I'll note the caches were already designed to reprocess contexts based on whichever active context they were based, so that a "path" of sorts wouldn't be needed.

I'll note, however, that there's a difference between the implementations in how this layered caching is implemented. jsonld.js uses an active context object itself as a key in the ResolvedContext LRU cache:

https://github.com/digitalbazaar/jsonld.js/blob/v8.3.3/lib/ResolvedContext.js#L24

And pyld uses a private _uuid property of the active context:

https://github.com/digitalbazaar/pyld/blob/v2.0.4/lib/pyld/resolved_context.py#L32

However, it looks like the python version does not generate a new _uuid property when cloning an active context for modification:

https://github.com/digitalbazaar/pyld/blob/v2.0.4/lib/pyld/jsonld.py#L5619

Which seems like the most natural place to do this in order for it to be a "unique object identifier", similar to using the object reference itself in jsonld.js (presumably this can't be done as easily in python).

I do see a few places where the _uuid is manually added if not present:

https://github.com/digitalbazaar/pyld/blob/v2.0.4/lib/pyld/jsonld.py#L3069-L3070
https://github.com/digitalbazaar/pyld/blob/v2.0.4/lib/pyld/jsonld.py#L3144-L3145

(based on a search).

These may just be insufficient -- and it would be simpler to always add this property (with a new value) when creating a new active context, since this property is meant to represent a unique, in-memory object reference.

I recommend getting a test case together and then just trying adding a _uuid property with a new value to every cloned active context to see if it passes (and that there are no regressions). It would also be good, of course, to determine whether jsonld.js passes this test too.

@tsdrone,

Please feel free to experiment based on the above notes as well -- and thank you for the PR.