Evaluate replacing the hand-written context walker with pyld

[LukasOro]

src/oold/validation/context_resolution.py hand-walks an OO-LD @context chain in about 300 lines to produce a flattened context. Its module docstring justified this by claiming a JSON-LD processor cannot consume these entries. That claim is false and has been corrected in #114; the code was left in place.

Evidence the premise was wrong

Pointing pyld at tests/data/oold/Person.schema.json as a remote context, with a document loader mapping the fixture directory:

doc = {"@context": "https://example.org/Person.schema.json", "name": "Ada"}
jsonld.expand(doc)
# -> [{"http://schema.org/name": [{"@value": "Ada"}]}]

It resolved, following the relative sibling Thing.schema.json and picking up the schema: prefix defined several hops up the chain. Per JSON-LD 1.1 a remote context document only needs a top-level @context; other entries are ignored. That is what OOLD-CMP-b926 guarantees by requiring an OO-LD schema to be usable as a context without further processing.

What is actually needed

The callers do not want expansion. They want the effective context as a value: which terms a schema defines and which hop each came from, for term reporting and the per-property attribution in src/oold/validation/predicates.py. pyld does return the flattened active context, through JsonLdProcessor.process_context - see #118 (comment) and the confirmation below it. What it does not carry is per-term provenance: mappings records no source document, so "which hop defined this term" has to be recovered by processing the chain a hop at a time and diffing.

Work

• Determine whether the effective context can be obtained from pyld without relying on private API, for example by expanding a probe document built from the schema's declared properties and reading back the mapping
• Compare the result against resolve_context() across the whole fixture corpus, including the scoped-context form {"@id": ..., "@context": "Other.schema.json"}
• If it holds, replace the walker; if it does not, record which specific capability is missing so the module has a justification that survives review

Constraint

rule.* and context.* verdicts must not move. The parity tests (OOLD_SCHEMA_DIR=../oold-schema uv run pytest -m parity) are the gate.

Raised from review of #114 (comment).

[simontaurus]

Checked: pyld does expose the flattened active context, through the public JsonLdProcessor.process_context.

p.process_context(p._get_initial_context({}), ctx_url, opts)['mappings']
  id         -> {"@id": "@id"}
  name       -> {"@id": "http://schema.org/name"}
  schema     -> {"@id": "http://schema.org/", "_prefix": true}
  type       -> {"@id": "@type"}
  works_for  -> {"@id": "http://schema.org/worksFor", "@type": "@id"}

Against tests/data/oold/Person.schema.json, which declares only schema and works_for: id, name and type are inherited from the relative sibling Thing.schema.json. So the chain is resolved and flattened, with @type, @container, protected, reverse and prefix flags per term.

Provenance is the only gap - mappings records no source document. That is obtainable by processing the chain one hop at a time and diffing, which is bookkeeping rather than a second implementation:

term provenance by diffing each hop:
  id           first defined by Thing.schema.json
  name         first defined by Thing.schema.json
  works_for    first defined by Person.schema.json

So the remaining justification does not hold for "which terms are in scope", only for "where each came from", and that half is ~10 lines on top of pyld. Worth replacing the walker rather than keeping a parallel implementation of context processing.

[LukasOro]

Confirmed independently, and you are right. Ran it against tests/data/oold/Person.schema.json with a loader mapping the fixture directory:

keys: ['_uuid', 'mappings', 'processingMode']
  id         -> {'@id': '@id',                            '_prefix': False, 'protected': False, 'reverse': False}
  name       -> {'@id': 'http://schema.org/name',         '_prefix': False, ...}
  schema     -> {'@id': 'http://schema.org/',             '_prefix': True,  ...}
  type       -> {'@id': '@type',                          '_prefix': False, ...}
  works_for  -> {'@id': 'http://schema.org/worksFor', '@type': '@id', ...}

Person.schema.json declares only schema and works_for, so id, name and type did come through the relative sibling Thing.schema.json. The chain is resolved and flattened, with prefix flags and @type per term.

I have corrected the issue body: the sentence claiming pyld exposes no public API for this was wrong, and leaving it would have justified the walker on a false premise.

Three things still to settle before the walker goes, none of them fatal:

• One of the two calls is still private. process_context is public, _get_initial_context is not. Either find a public route to the initial context, construct it directly, or accept the private call with a pinned pyld and a test that fails loudly on an upgrade. Worth deciding deliberately rather than discovering it in a release.
• x-oold-context is not a JSON-LD construct, so pyld will not see it. 7875b51 promotes those terms into the resolved context so a property mapped only there is not reported as dropped (OOLD-EXT-4966). That promotion stays on top of pyld whatever happens underneath.
• Scoped contexts in the {"@id": ..., "@context": "Other.schema.json"} form need checking against the corpus, as the issue already says.

On sequencing: after #120 rather than before it. 120 changes what context.predicates reports, and this issue's acceptance criterion is that verdicts do not move, so it needs 120's verdicts to be the settled ones. Then 119 after this, as you say there.