OOLD-EXT-eeda is a MUST:
An implementation that supports reverse properties reads them from, and writes an edit back to, the forward property on the referenced object.
This repository has no implementation of it. x-oold-reverse-properties appears nowhere in src/ or tests/, so a schema declaring one is parsed, validated and then ignored: the property is silently absent from the model.
The keyword is in the meta-schema (oold-meta-schema-base.json), and the specification carries a worked example across Organization and Person, so schemas using it validate today and simply do not work.
What the rule asks for
Given Organization declaring employees in x-oold-reverse-properties, mapped with @reverse to schema:worksFor, and Person carrying the forward works_for:
- Read: resolving
organization.employees yields the Person objects whose works_for points at that organization. Nothing is stored on the organization.
- Write: assigning to
organization.employees edits works_for on the referenced Person objects, not a field on the organization.
The read half is a query over the referenced objects, so it depends on a backend that can answer "which objects point here". That makes this backend-shaped work rather than a pure model change, and it is worth deciding up front which backends can support it and what the others do instead: raise, return empty, or leave the attribute absent.
Not the same as a plain @reverse term
A property mapped with @reverse in the @context is a read projection that JSON-LD handles on its own, with no OO-LD keyword involved and no write path. x-oold-reverse-properties is the editor affordance that adds the write path. OO-LD/oold-schema#181 states the distinction, which the specification previously left in a parenthetical.
The frame derivation already treats both as reference-valued (#164), so framing is correct either way. This issue is about the model and backend layers, where nothing exists yet.
Scope note
Worth confirming whether this is wanted before 1.0 of the library or after. The rule is conditional in form, "an implementation that supports reverse properties", so not implementing it is conformant. What is not tenable is the current state, where a declared reverse property looks supported and does nothing.
OOLD-EXT-eedais a MUST:This repository has no implementation of it.
x-oold-reverse-propertiesappears nowhere insrc/ortests/, so a schema declaring one is parsed, validated and then ignored: the property is silently absent from the model.The keyword is in the meta-schema (
oold-meta-schema-base.json), and the specification carries a worked example acrossOrganizationandPerson, so schemas using it validate today and simply do not work.What the rule asks for
Given
Organizationdeclaringemployeesinx-oold-reverse-properties, mapped with@reversetoschema:worksFor, andPersoncarrying the forwardworks_for:organization.employeesyields thePersonobjects whoseworks_forpoints at that organization. Nothing is stored on the organization.organization.employeeseditsworks_foron the referencedPersonobjects, not a field on the organization.The read half is a query over the referenced objects, so it depends on a backend that can answer "which objects point here". That makes this backend-shaped work rather than a pure model change, and it is worth deciding up front which backends can support it and what the others do instead: raise, return empty, or leave the attribute absent.
Not the same as a plain
@reversetermA property mapped with
@reversein the@contextis a read projection that JSON-LD handles on its own, with no OO-LD keyword involved and no write path.x-oold-reverse-propertiesis the editor affordance that adds the write path. OO-LD/oold-schema#181 states the distinction, which the specification previously left in a parenthetical.The frame derivation already treats both as reference-valued (#164), so framing is correct either way. This issue is about the model and backend layers, where nothing exists yet.
Scope note
Worth confirming whether this is wanted before 1.0 of the library or after. The rule is conditional in form, "an implementation that supports reverse properties", so not implementing it is conformant. What is not tenable is the current state, where a declared reverse property looks supported and does nothing.