ontology: register AI Weed Library field & observation schemas (v2)

[stelsp]

Description of change

Registers nine schemas written by the AI Weed Library platform (map viewer for Dutch crop fields — claim a field, upload field photos as observations, share fields with other eNames). The platform has been writing these ids since its v2 model went live; nothing on the network can resolve them until they land here.

Seven implement spec articles W-A-15 … W-A-23. Two are app-profile and labelled as such.

schemaId	File	Type	Article
a1abfd8e-4f0a-4c1d-98de-f351586c03e8	logicalField.json	LogicalField — durable identity of one managed field; the anchor everything else points at	W-A-15
f577eb36-8230-494d-866b-45af25e83f16	fieldClaim.json	FieldClaim — periodised owner / tenant / manager assertion, with method + provenance	W-A-16
207a6b1a-19b4-468d-9641-68ba661c2291	fieldBoundary.json	FieldBoundary — one source's geometry for one validity period (RFC 7946, plus optional source geometry + sourceCrs)	W-A-17
339723ce-4771-48d6-a7e1-a0fdf736d584	fieldLink.json	FieldLink — provenanced join from a boundary to its LogicalField	W-A-18
a9723f8c-9aa1-48ff-9698-9447353736c3	observation.json	Observation — the act: type, phenomenonTime, observer, optional footprint / pin. No field ref, no files inside	W-A-19
772ea2b3-82e7-4ce3-9a4d-a4445c57bd6c	observationRelation.json	ObservationRelation — optional binding to a LogicalField (about / covers / intersects)	W-A-20
65586839-24ad-4875-921e-578e3c284a0f	mediaAsset.json	MediaAsset — one photo: fileRef, capturedAt, optional EXIF point	W-A-23
bef1033f-ecbd-4ffd-a36a-e30fe521f2ef	observationAttributes.json	app-profile: agronomic sidecar (crop, sowing date, weeds, price, device) + the observation's access policy. W-A-19 keeps these out of the Observation and there is no canonical home yet	—
63d0e376-2522-4799-b82d-990267965dd9	fieldAccessGrant.json	app-profile: "share this field" grant — grantee, role, owner-canonical / grantee-reference envelope pair, keyed on logicalFieldRef	—

The ids are live in a running deployment (envelopes carry them, AaaS subscriptions route on them), so please do not renumber. Random UUIDv4s; 64 unique ids and titles after this change.

Conventions: draft-07, additionalProperties: false, everything a consumer relies on in required; cross-envelope references are w3ds://<ename>/<envelopeId> strings, never copies; every type carries schemaVersion / recordedAt / optional supersedes + deleted; one shared method enum (user-confirmed / source-provided / geometry-derived) with confidence and algorithm for the derived case. The files are emitted from the platform's typed contracts, which a golden test pins on our side, and are added here verbatim.

Two deviations, recorded

1. LogicalField is the anchor, not FieldBoundary. W-A-16 and W-A-20 anchor claims and relations to a boundary; we anchor both to the LogicalField so they survive the yearly boundary rollover, with FieldBoundary kept as versioned source geometry joined through FieldLink. Everything carries supersedes, so a canon that lands differently stays survivable.
2. No File envelope. uploadFile already creates a w3ds-file-v1 blob envelope per upload and dispatches its awareness packet, so MediaAsset.fileRef points at that directly rather than duplicating it under a W-A-22 record. The existing File schema (a1b2c3d4-…) is therefore not what fileRef targets.

Nothing registered covers this: AccessGrant is a generic resource grant and would lose the role vocabulary and the logicalFieldRef join; Relation (#1103) is an untyped reified triple with no provenance fields; no schema models fields, boundaries, claims or observations.

Notes for reviewers

• All nine declare "domain": "agriculture" (already in the published Domain list as "Food & agriculture"), emitted from the platform's contracts so our artifacts carry the same value.
• No property-level descriptions: the files are machine-emitted and semantics live in the articles above. Happy to add them.
• camelCase filenames and 2-space formatting, per the directory's 2026 registrations.

Issue Number

n/a

Type of change

• New (a change which implements a new feature)

How the change has been tested

Booted services/ontology from this branch: Loaded 64 schemas, Loaded 20 domains, no missing-schemaId warnings. GET /schemas lists all nine; GET /schemas/<id> returns each file byte-for-byte; the viewer renders them; unknown ids still 404. No duplicate id or title across the 64 files.

Change checklist

• I have ensured that the CI Checks pass locally (the ontology service defines no check/format/build scripts; it boots and serves the new files as above)
• I have removed any unnecessary logic
• My code is well documented — no property-level descriptions, see the reviewer note
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: b1da288e-04b1-47b1-bfdd-1949c90de08f

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

@stelsp can you please add domains to these, please see other examples in the ontologies which contain domain information

[stelsp]

Done — "domain": "agriculture" on all nine (eec34c7). It was already in the published Domain list as "Food & agriculture", so nothing new had to be registered.

The value is emitted from the platform's contracts, so the artifacts we ship carry the same line; the schemas are otherwise unchanged. Commits are signed now as well.

[stelsp]

Thanks for merging. One question: when is the ontology service next redeployed?

The nine ids still 404 on https://ontology.w3ds.metastate.foundation — expected, since the service indexes the schema files once at boot (loadSchemas() before app.listen), so the running instance keeps serving what it read at startup. A partner team is about to resolve these ids against the hosted registry, so it would help to know roughly when the restart lands — or whether redeploys are triggered on merge to main and this one simply has not run yet.