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

[stelsp]

Description of change

Registers the nine JSON Schemas written by the AI Weed Library platform (a map viewer for Dutch crop fields: farmers claim fields, upload field photos as observations, and share fields with other eNames; the user's eVault is the source of truth, the platform keeps only derived caches). The platform has been writing these types under the schemaIds below since its v2 data model went live; nothing else on the network can resolve them until they are registered here.

Seven are canonical W3DS agriculture entities implementing the ontology spec articles W-A-15 … W-A-23; two are app-profile types and are labelled as such.

Type	What it is	Article
LogicalField	Durable identity of "one managed field"; the anchor claims, links, relations and grants point at.	W-A-15
FieldClaim	Periodised ownership/tenancy assertion (owner / tenant / manager) on a LogicalField, with method + provenance.	W-A-16
FieldBoundary	One spatial representation of a field from one source (RVO/BRP, FarmMaps, user-drawn) for one validity period; RFC 7946 geometry plus optional source geometry + sourceCrs.	W-A-17
FieldLink	Provenanced join between a FieldBoundary and the LogicalField it represents.	W-A-18
Observation	The act of observing: type, phenomenonTime (instant or interval), observedBy / uploadedBy, optional footprint / pinPoint. No field reference and no files inside it.	W-A-19
ObservationRelation	Optional provenanced binding of an Observation to a LogicalField (about / covers / intersects); an observation is valid with zero relations.	W-A-20
MediaAsset	One photo of an observation: fileRef to the blob envelope, capturedAt, optional EXIF-derived Point geometry, pixel size.	W-A-23
ObservationAttributes — app-profile sidecar, not a canonical W3DS entity	Per-observation agronomic attributes (crop, sowing date, weeds, price, comment, device) and the observation's access policy (accessLevel + allowedEnames). W-A-19 keeps these out of the Observation payload and there is no canonical home for them yet, so they live in one sidecar envelope per observation.	—
FieldAccessGrant (v2) — app-profile, not a canonical W3DS entity	The platform's own "share this field" grant: grantee eName, role (viewer / contributor / manager), canonical-in-owner-vault + reference-in-grantee-vault (isReference, canonicalOwnerEName, canonicalEnvelopeId). Version 2 of the platform's grant, keyed on logicalFieldRef. Access mechanics, deliberately outside the canonical ontology.	—

schemaId ↔ file

schemaId	File	Title
a1abfd8e-4f0a-4c1d-98de-f351586c03e8	services/ontology/schemas/logicalField.json	LogicalField
207a6b1a-19b4-468d-9641-68ba661c2291	services/ontology/schemas/fieldBoundary.json	FieldBoundary
f577eb36-8230-494d-866b-45af25e83f16	services/ontology/schemas/fieldClaim.json	FieldClaim
339723ce-4771-48d6-a7e1-a0fdf736d584	services/ontology/schemas/fieldLink.json	FieldLink
a9723f8c-9aa1-48ff-9698-9447353736c3	services/ontology/schemas/observation.json	Observation
772ea2b3-82e7-4ce3-9a4d-a4445c57bd6c	services/ontology/schemas/observationRelation.json	ObservationRelation
bef1033f-ecbd-4ffd-a36a-e30fe521f2ef	services/ontology/schemas/observationAttributes.json	ObservationAttributes
65586839-24ad-4875-921e-578e3c284a0f	services/ontology/schemas/mediaAsset.json	MediaAsset
63d0e376-2522-4799-b82d-990267965dd9	services/ontology/schemas/fieldAccessGrant.json	FieldAccessGrant

These ids are already in use by a running deployment — envelopes carrying them exist in eVaults and the platform's AaaS subscriptions route on them — so please do not renumber them. They were generated as random UUIDv4s and collide with nothing in schemas/ (checked: 64 unique ids, 64 unique titles after this change).

Design rules followed

• Draft-07, additionalProperties: false everywhere, every field a consumer can rely on listed in required.
• Links, never copies: cross-envelope references are w3ds://<ename>/<envelopeId> strings (logicalFieldRef, boundaryRef, observationRef, fileRef, supersedes); eNames are plain strings.
• Every app-written type carries the same common block: schemaVersion, recordedAt, optional supersedes (same-type only; retraction = a superseding record) and optional deleted tombstone flag.
• Provenance is explicit and uniform: one method enum (user-confirmed / source-provided / geometry-derived) on claims, links and relations, with confidence + algorithm + algorithmVersion for the derived case.
• Conditional requirements are expressed with dependencies (geometry → geometryProvenance, footprint → footprintType, sourceGeometry → sourceCrs).
• The files are the JSON Schema artifacts emitted from the platform's typed contracts (one definition, used as the write gate on the platform side and published here); they are checked in on the platform side and a golden test in its suite fails whenever a schema drifts from the contract. They are added here verbatim.

Two recorded deviations from the spec text

1. LogicalField is the land anchor. W-A-16 and W-A-20 as written anchor FieldClaim and ObservationRelation to a FieldBoundary. We anchor both to the LogicalField (logicalFieldRef) so claims and bindings survive the yearly boundary rollover; FieldBoundary stays the versioned source geometry joined through FieldLink. Everything written carries supersedes chains, so a canon that lands differently remains survivable.
2. No canonical File envelope. W-A-22 describes a File entity. We do not write one: the eVault uploadFile operation already creates a w3ds-file-v1 blob envelope per upload (filename, contentType, size, publicUrl, uploadedAt) and dispatches an awareness packet for it, so MediaAsset.fileRef points at that blob envelope directly. Writing a File record next to it would duplicate the same data under a second id. This also means the existing File schema in this registry (a1b2c3d4-…) is not what fileRef targets.

Could an existing schema have carried this?

• File (a1b2c3d4-…) — see deviation 2; MediaAsset is the per-observation link + capture metadata, not a file record.
• AccessGrant (15d24c04-…) — a generic resource/permission grant. FieldAccessGrant is scoped to one LogicalField with a fixed three-role vocabulary and the owner-canonical / grantee-reference envelope pair the platform relies on; forcing it into AccessGrant would lose the role semantics and the logicalFieldRef join. Kept separate and labelled app-profile.
• Relation (Meshenger, Register seven Meshenger-authored ontologies (Relation, AvailabilityStatus, ChatPreference, DraftMessage, Summary, PreferredHandlers, FileContext) #1103) — a reified triple between arbitrary envelopes. ObservationRelation and FieldLink are typed, provenanced joins with their own relation vocabularies and method/confidence fields; a generic Relation would not carry them.
• No existing schema models fields, boundaries, claims or observations.

Notes for reviewers

• No domain is set on these files, same as the CallSession, Meshenger and docusigner registrations. If you would like "domain": "agriculture" added, say so and I will add it in this PR.
• Property-level descriptions are not present because the files are machine-emitted artifacts; field semantics are in the spec articles referenced above. Happy to add them if required.
• Filenames follow the camelCase-of-title convention used by every 2026 registration; formatting is the directory's majority 2-space style.

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, zero "missing schemaId" warnings.
• GET /schemas lists all nine with the titles above; GET /schemas/<id> returns 200 and the exact file content for each of the nine; GET /schema/<id> (viewer) renders; an unknown id still 404s.
• Verified no duplicate schemaId or title across the 64 files.
• On the platform side the same nine files are covered by a golden test against the typed contracts they are emitted from.

To reproduce after merge/redeploy: curl https://ontology.w3ds.metastate.foundation/schemas/a1abfd8e-4f0a-4c1d-98de-f351586c03e8 (and the other eight ids above).

Change checklist

• I have ensured that the CI Checks pass locally (the ontology service defines no check/format/build scripts; the service boots and serves the new files as described above)
• I have removed any unnecessary logic
• My code is well documented
• 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: 08f76504-37e5-4dad-bb3a-da212d6b0d55

---

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.}