context.predicates reports unmapped properties under a rule about prefixes

[LukasOro]

context.predicates reports two distinct findings but cites one rule, and the second finding has no rule behind it.

What it reports

Finding	Message	Matches the cited rule?
suspicious	a term expands to a syntactically absolute IRI whose prefix is undefined	yes
dropped	property with no @context term: <name>	no

The check cites OOLD-EXT-2b61, whose specification text is:

Compact form specifically - a "pattern" such as "^[A-Za-z_][\w.-]:(?!//)\S$", which accepts ex:alice and schema:Person while rejecting http://...; the prefix MUST be defined in the @context.

That is a rule about compact-IRI prefixes. It does not require every property to carry a term.

Why it matters

Severity is read from the cited rule's level. OOLD-EXT-2b61 is a MUST, so the dropped-property finding is reported as a failure on the authority of a rule that does not state it.

Searching the 66-rule catalogue in src/oold/validation/meta/1.0.0-rc.2/oold-rules.json finds no rule requiring complete context coverage. Raised in review as "complete context coverage is not mandatory".

For contrast

roundtrip.generated reports the same situation as "property lost through RDF" and cites no rule (rule=None). That is defensible on its own terms: round-trip fidelity is this package's own promise rather than a specification requirement, and it is reported without borrowing normative authority.

Work

• Split the two findings so the prefix half keeps citing OOLD-EXT-2b61 and the coverage half does not
• Decide what the coverage half is: a package-level lint like roundtrip.generated, a warning, or something that needs a rule upstream in oold-schema
• If it stays, it must not claim MUST severity from an unrelated rule

Raised from review of #114 (#114 (comment)).

[simontaurus]

Stronger than "no rule requires coverage": the spec explicitly permits the opposite.

spec/sections/02-introduction.md:48:

a term exists as a plain structural property with no semantics attached; an author MAY leave it unmapped, map it to a single IRI, or map it to several concurrent IRIs. An unmapped term produces no triples under JSON-LD expansion; to prevent such terms from being dropped silently, an author MAY declare @vocab [...]

Deferring semantics is stated there as the differentiator from RDF/SHACL: "they cannot withhold semantic commitment, OO-LD can." So failing on an unmapped property does not merely cite the wrong rule, it inverts a design goal.

Two fixes, in two repos:

• Here: the dropped-property half must not fail and must not cite OOLD-EXT-2b61. A warning citing no rule, like roundtrip.generated, matches what the specification actually says.
• In oold-schema: that permission sits in {#introduction .informative}, so it carries no normative force and nothing can cite it. It should be stated in normative prose. It will not get a rule id either way - MAY is not in the extractor's level vocabulary, since the catalogue tracks obligations - but normative is where a load-bearing permission belongs.

Worth checking @vocab interacts as that paragraph says before settling the warning text: with @vocab declared, an otherwise-unmapped term does get an IRI, so the finding should not fire at all there.

[simontaurus]

Resolution agreed: warn, do not fail, and keep the strict behaviour behind an opt-in flag.

The strict full-round-trip expectation was designed around the specification's own reference examples, where every term is mapped by construction; generalised to arbitrary schemas it rejects documents the specification permits.

Upstream half is open as OO-LD/oold-schema#137, which states the permission normatively and adds OOLD-SCH-2d05 (MUST NOT, applies=implementation): an implementation must not treat an unmapped term as a conformance failure, but may report one, or reject it under a strict mode the user opts into. That gives this check something to cite instead of OOLD-EXT-2b61.

Work here:

• split the two findings; the prefix half keeps OOLD-EXT-2b61
• the coverage half warns, and cites OOLD-SCH-2d05 once rc.3 is vendored
• add --strict to promote it back to a failure
• the message should name the two fixes: declare @vocab, or add the mapping to x-oold-context
• it must not fire at all when @vocab is declared, since the term is then mapped

[LukasOro]

Resolution accepted, on all five points. One of them turns out to be already satisfied, so it can come off the list.

@vocab already suppresses the finding. Checked rather than assumed, with a two-case probe against --meta latest, one property and no term for it:

@context	context.predicates	detail
{"@version": 1.1, "@vocab": "https://example.org/vocab/"}	ok	mapped: 1, aliased: 0
{"@version": 1.1}	fail	dropped: ['unmapped_term']

So with @vocab declared the term is counted as mapped and nothing fires, which is what that paragraph of the specification says should happen. The @vocab work item is a no-op, and the second row is exactly the behaviour this issue exists to change: a FAIL, citing OOLD-EXT-2b61, on a document the specification explicitly permits.

Remaining work, updated:

• split the two findings; the prefix half keeps OOLD-EXT-2b61
• the coverage half warns and cites OOLD-SCH-2d05 once rc.3 is vendored
• --strict promotes it back to a failure
• the message names both fixes: declare @vocab, or add the mapping to x-oold-context
• must not fire when @vocab is declared already holds; worth a regression test so it keeps holding through the split

One interaction to keep in view: #127. predicates.py:112 returns DROPPED when jsonld.expand raises, the same status as a genuinely unmapped term, differing only in a detail string. Once the unmapped case becomes a warning, a pyld failure would silently be downgraded with it unless the two are separated first. PredicateResult.errors exists for that and is never written.

Upstream OO-LD/oold-schema#137 is green and mergeable.