Extending the schema

How Rhetornet and other projects build on the Electepedia core.

Note

Status: proposal. These are the rules Rhetornet will follow first. They may change while both projects are at 0.x.

Projects under the Electepedia umbrella share one core schema: people, organizations, roles, events, sources, statements, claims and fact-checks. Each project adds its own types in a separate extension schema that imports the core. A person, statement or claim has the same meaning and identifier everywhere, and each project can still model what only it needs.

The rules

Import the core; don’t copy or edit it. An extension lists the core in its imports. Keep a pinned copy of the core in your repo (e.g. vendor/electepedia.yaml), note which version it is, and update it on purpose. Don’t import the live URL, which always serves the latest version.
Use your own namespace for terms. Rhetornet’s terms live under https://electepedia.com/schema/rhetornet/. Record IDs still use the shared elp: prefix with a type path, e.g. elp:segment/....
Point at core records; don’t redefine them. Use core classes as ranges: a segment’s speaker is a core Person, and a transcript’s recording is a core Source. Never create a separate person or source class.
Specialize by subclass. If you need a core class with extra slots, add a subclass (is_a: Event). If it’s only a different kind of thing, use the existing enum (event_type: debate). Don’t add slots to core classes from the extension; propose them for the core instead.
Only core records flow back to Electepedia. What an extension publishes to Electepedia is a plain core Dataset (statements, claims, events, sources) and can be loaded with python -m storage load. Extension-only records (transcripts, segments, annotations) stay in the extension’s own storage.
Automated output is unverified until a person reviews it. Records a pipeline creates set recorded_by to the pipeline and its version (e.g. pipeline:rhetornet-asr@v1) and keep record_status: unverified. Statements taken from an automatic transcript use quote_type: transcript_excerpt until someone checks them against the recording. Labels like a detected fallacy are never attached to a named person publicly without that review.
Promote to the core when Electepedia needs it. If Electepedia needs to store or display an extension type, for example fallacy annotations on a profile page, it moves into the core in a reviewed schema change.

Rhetornet, sketched

Rhetornet transcribes debates, works out who is speaking, and labels the rhetoric. Its extension adds:

Class	What it is	Links to the core
`RhetornetDataset`	A core `Dataset` plus the records below	`is_a: Dataset`
`Transcript`	One speech-to-text run over one recording	`event` → `Event`, `recording` → `Source`
`SpeakerAssignment`	Maps a diarization label (`SPEAKER_00`) to a person	`person` → `Person`
`TranscriptSegment`	A stretch of speech by one speaker, with timings	`statement` → `Statement`, once published
`RhetoricalAnnotation`	A label on one or more segments (fallacy, off-topic, topic shift), with confidence	`HasProvenance`; maps to W3C Web Annotation

The flow from a debate recording to Electepedia:

flowchart LR
  rec[Recording<br/>core Source] --> tr[Transcript]
  tr --> seg[TranscriptSegment]
  tr --> spk[SpeakerAssignment] --> person[core Person]
  seg --> ann[RhetoricalAnnotation]
  seg -- reviewed --> st[core Statement] --> claim[core Claim]

The sketch is tested in the Electepedia repo (schema/examples/extension/), so a core change that breaks extensions fails CI. The real Rhetornet schema lives in the Rhetornet repo and starts from that sketch.