org.cannadb.strainEdit

A field-level edit to a strain's living document (collaborative editing). Targets a strain via `subject` (the anchor record of the entity) and carries a sparse patch: scalar field overwrites in `set`, additive ops on open array fields in `add`/`remove`, and field clears in `unset`. The AppView folds accepted edits over the anchor record to materialize the canonical document; this record is one signed contribution, attributed to its publisher DID. See docs/05-collaborative-strains.md.

Repository @cannadb.org did:plc:lrtzzib3ycggsodkfidzuorw namespace authority
Details · record, key tid
Kindrecord
Record keytid
Authoritycannadb.org
Indexed

Record

record · key tid

Properties

add

ref

Values to add to open array fields (union at fold time).

Reference

basedOn

string

Materialized revision hash this edit was authored against, for conflict detection. Optional; absent for blind edits.

createdAt

requiredstring · datetime

Client-declared timestamp when this edit was created. Also the fold ordering key (ties broken by record URI).

Values to remove from open array fields (set-difference at fold time).

Reference

set

ref

Scalar and object-valued fields to overwrite (last-writer-wins per field at fold time).

Reference

subject

requiredstring · at-uri

AT-URI of the org.cannadb.strain record anchoring the entity this edit targets.

summary

string

Short human edit summary (the commit message). Capped at 200 graphemes (2000 bytes).

  • maxLength: 2000
  • maxGraphemes: 200

unset

array

Field names to clear. Each must be an editable field of org.cannadb.strain.

itemsstring

An editable strain field name to clear, e.g., "growthOdour".

#arrayFields

object

Open array fields that support additive add/remove merge. Lineage arrays (parents/versionOf and their parallel name arrays) are NOT here — they are replaced wholesale via `set` because their parallel-index structure does not merge element-wise.

Properties

itemsstring
itemsstring

effects

array
itemsstring

flavors

array
itemsstring
itemsstring
itemsstring
  • knownValues: regular | feminized | autoflower | clone_only
itemsstring

#scalarFields

object

The strain's scalar and object-valued fields, all optional. Mirrors org.cannadb.strain. Range/yield objects reference the same shapes the strain lexicon defines. Identity fields (name, kind, breeder, holder) are expressible here; whether such an edit is accepted is an AppView fold/governance concern, not a lexicon constraint.

Properties

autoflower

boolean

breeder

string · at-uri
  • knownValues: easy | intermediate | hard
  • knownValues: low | medium | high

holder

string · at-uri
  • minimum: 0
  • maximum: 100

kind

string
  • knownValues: strain | cut

name

string

originYear

integer
itemsstring
itemsstring

parents

array
itemsstring · at-uri

sourceUrl

string · uri
itemsstring · at-uri
itemsstring

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • Cannabis genetic identity. The same record type covers two levels of specificity, distinguished by the `kind` field: "strain" denotes a broad genetic identity (e.g., "Wedding Cake"); "cut" denotes a specific phenotype, clone, or keeper pheno (e.g., "Forum cut of GSC"). Captures intrinsic identity, structured cultivation profile, and the publisher's contextualized field assertions; subjective experience and measured outcomes live in separate record types (`org.cannadb.review`, future `org.cannadb

  • A review of a cannabis strain or cut. Reviews are where subjective experience lives — the reviewer's perceived flavors and effects, multi-axis ratings, prose body, and optional images. Reviews reference exactly one strain record via `subject` and aggregate at the AppView layer into per-strain summaries (community-derived effect/flavor percentages, average ratings). Publishing this record IS the claim — every field is contextualized by the publisher DID at display time. CannaDB editorial accounts

  • A single plant within a grow. The plant is the lifecycle unit: it references the `org.cannadb.grow` it belongs to and (optionally) the `org.cannadb.strain` it is. Its lifecycle stage is NOT stored as a mutable field here — stage transitions are append-only `org.cannadb.growEntry` events (kind "stage"), and the AppView computes the current stage from the latest such event. Measured harvest outcomes, once known, are recorded in the optional `harvest` object so the AppView can aggregate real cultiv