Core Vocabulary v3.6

Cross-application schema versioning, provenance, and identity

Overview

Namespace URI:
https://ns.cascadeprotocol.org/core/v1#
Preferred Prefix:
cascade:
Version:
3.6
Status:
Stable
Schema File:
core.ttl (Turtle/RDF)

The Core Vocabulary defines cross-cutting concepts used by all Cascade Protocol health data applications. It provides essential infrastructure for schema versioning, data provenance tracking, and user identity management. Domain-specific vocabularies (e.g., pots:, ecg:) import this core vocabulary.

Download TTL Back to Documentation

Classes

cascade:DataProvenance

owl:Class

Classification of how health data was generated or collected. All data in the Cascade Protocol is tagged with provenance to distinguish consumer-generated wellness data from clinical-grade diagnostics.

Subclass of: prov:Entity

cascade:ConsumerGenerated

owl:Class

Data generated directly by the user through personal devices in a non-clinical setting (e.g., Apple Watch POTS check).

Subclass of: cascade:DataProvenance

Disjoint with: cascade:ClinicalGenerated

cascade:ClinicalGenerated

owl:Class

Data generated in a clinical setting under healthcare provider supervision (e.g., hospital ECG, lab results).

Subclass of: cascade:DataProvenance

Disjoint with: cascade:ConsumerGenerated

cascade:DeviceGenerated v1.2

owl:Class

Data generated by a consumer health device (Apple Watch, blood pressure cuff, etc.) without clinical supervision.

Subclass of: cascade:ConsumerGenerated

cascade:SelfReported v1.2

owl:Class

Data manually entered by the patient (symptom logs, medication adherence, intake form fields).

Subclass of: cascade:ConsumerGenerated

cascade:ConsumerWellness v1.2

owl:Class

Aggregated wellness data from consumer platforms (Apple Health, Google Fit).

Subclass of: cascade:ConsumerGenerated

cascade:EHRVerified v1.2

owl:Class

Data imported from a verified Electronic Health Record system (Epic MyChart, Cerner, etc.).

Subclass of: cascade:ClinicalGenerated

cascade:ScannedDocument v1.2

owl:Class

Data extracted from a scanned or photographed clinical document.

Subclass of: cascade:ClinicalGenerated

cascade:AIExtracted v1.2

owl:Class

Data extracted from clinical documents using AI/NLP processing. Clinically grounded: as of clinical v1.9 this is a permitted cascade:dataProvenance value on every clinical record shape.

Subclass of: cascade:ClinicalGenerated

cascade:AIAsserted v3.3

owl:Class

Content surfaced by a general-purpose AI assistant in a patient-directed conversation (e.g. ChatGPT, Claude), not grounded in clinical sources. MUST be applied to assertions imported from AI conversations so they can never be mistaken for clinically-extracted data (cascade:AIExtracted) or verified records (cascade:EHRVerified). Marks content that must be evidence-checked before any reliance.

Subclass of: cascade:ConsumerGenerated

Data Source v1.1

cascade:DataSource

owl:Class

Identity and reliability metadata for a data-producing device, app, or system. Examples: Apple Watch, MyChart EHR, manual user entry.

Subclass of: prov:Agent

cascade:sourceName

owl:DatatypeProperty

Human-readable name of the data source (e.g., 'Apple Watch Series 10', 'MyChart', 'Manual Entry').

Domain: cascade:DataSource

Range: xsd:string

cascade:sourceBundleId

owl:DatatypeProperty

App bundle identifier (e.g., 'com.apple.health'). Maps to HKSource.bundleIdentifier on Apple platforms.

Domain: cascade:DataSource

Range: xsd:string

cascade:sourceReliabilityTier

owl:DatatypeProperty

Reliability classification: 'clinical' (lab equipment, EHR), 'medical_device' (FDA-cleared BP cuff), 'consumer_device' (smartwatch, fitness tracker), 'self_reported' (manual entry). Tiers inform display and conflict resolution — they do not imply clinical validity.

Domain: cascade:DataSource

Range: xsd:string

cascade:sourceMetricCoverage

owl:ObjectProperty

A wellness metric this source provides. Use multiple triples for multiple metrics. Preferred over comma-separated strings for proper RDF graph traversal.

Domain: cascade:DataSource

Advisory & AI Generation Provenance v3.1–v3.2

PROV-O activities recording how advisory patches are applied and how LLM-generated narrative content is produced.

cascade:AdvisoryApplicationActivity v3.1

owl:Class (prov:Activity)

An activity that applied a Cascade Advisory Patch (CAP) to a Pod. Joins to advisory provenance via prov:used <advisory-iri> and prov:used <matched-record-iri>, recording both the patch source and the record it was matched against. Use prov:wasGeneratedBy on records produced or modified by the patch.

Subclass of: prov:Activity

cascade:AIGenerationActivity v3.1

owl:Class (prov:Activity)

An LLM-powered generation activity that produced narrative or summary content (e.g. checkup:VariantNarrative chunks). Sibling of cascade:AIExtractionActivity: extraction pulls structured records out of unstructured text, generation produces new prose. Reuses cascade:extractionModel, cascade:extractionConfidence, cascade:sourceNarrativeSection, and cascade:requiresUserReview; adds cascade:promptVersion, cascade:generationTemperature, and cascade:trigger. Link generated content via prov:wasGeneratedBy.

Subclass of: prov:Activity

cascade:promptVersion v3.1

owl:DatatypeProperty

Identifier of the prompt template version used for this generation, e.g. "variant-narrative-v2.1". Pair with cascade:extractionModel for full reproducibility.

Domain: cascade:AIGenerationActivity

Range: xsd:string

cascade:generationTemperature v3.1

owl:DatatypeProperty

Sampling temperature used during generation (typically 0.0–1.0). Recorded for reproducibility and to distinguish deterministic from creative outputs.

Domain: cascade:AIGenerationActivity

Range: xsd:decimal

cascade:trigger v3.1

owl:ObjectProperty

The reason this generation activity ran. One of the cascade:GenerationTrigger named individuals: cascade:InitialGeneration (first-time generation, no prior version), cascade:RegenerationAfterReclassification (upstream classification changed and the prior narrative is stale), cascade:AudienceRetargeting (retarget existing content for a different audience without any underlying classification change).

Domain: cascade:AIGenerationActivity

Range: cascade:GenerationTrigger

cascade:appliedTriplesCount v3.2

owl:DatatypeProperty

Total number of triples the advisory's CAP body inserted into the Pod for a single match. Lets an auditor verify CAP profile constraint C5 (≤ 64 inserted triples per match) at activity-record-read time without re-parsing the patch body.

Domain: cascade:AdvisoryApplicationActivity

Range: xsd:nonNegativeInteger

Caregiver Proxy v3.3

Records a person operating a patient's Pod on the patient's behalf (e.g. a parent for a minor child, a caregiver for a dependent adult). Added for the Cascade Workbench.

cascade:ProxyAgent v3.3

owl:Class (prov:Agent)

A person operating a patient's Pod on the patient's behalf. Distinct from the patient (cascade:PatientProfile). Records who is acting and under what authority and scope.

Subclass of: prov:Agent

cascade:actsForPatient v3.3

owl:ObjectProperty

The patient (WebID) on whose behalf the proxy acts. Subproperty of prov:actedOnBehalfOf.

Domain: cascade:ProxyAgent

Range: rdfs:Resource

cascade:proxyWebID v3.3

owl:ObjectProperty

WebID of the proxy agent.

Domain: cascade:ProxyAgent

Range: rdfs:Resource

cascade:proxyRelationship v3.3

owl:DatatypeProperty

Relationship of the proxy to the patient. Reuses the cascade:contactRelationship value space: parent, guardian, caregiver, spouse, child, other.

Domain: cascade:ProxyAgent

Range: xsd:string

cascade:proxyScope v3.3

owl:DatatypeProperty

Authority scope, e.g. full, read-only, investigation-only. Composable with cascade:consentScope (data-sensitivity), which it does not replace.

Domain: cascade:ProxyAgent

Range: xsd:string

cascade:proxyGrantedAt v3.3

owl:DatatypeProperty

When proxy authority was granted.

Domain: cascade:ProxyAgent

Range: xsd:dateTime

cascade:proxyRevokedAt v3.3

owl:DatatypeProperty

When proxy authority was revoked, if applicable.

Domain: cascade:ProxyAgent

Range: xsd:dateTime

Data Properties

cascade:schemaVersion

owl:DatatypeProperty

Semantic version of the ontology schema used to serialize this data (format: major.minor.patch).

Range: xsd:string

Example: "1.2", "2.0.1"

See also: Semantic Versioning

cascade:dataProvenance

owl:ObjectProperty

Classification of how this data was generated (consumer vs clinical).

Range: cascade:DataProvenance

Example: cascade:ConsumerGenerated

cascade:creatorWebID

owl:ObjectProperty

Solid WebID URI of the user who created this data. Used for access control and data ownership tracking.

Subproperty of: prov:wasAttributedTo

Range: rdfs:Resource

Example: <https://id.cascadeprotocol.org/users/abc123>

See also: WebID Specification

Provenance Detail Properties v2.3

Lightweight record-level provenance properties for attribution display in Health Map provenance badges. Applied directly to record instances (not DataSource objects) to enable attribution display without full graph traversal.

cascade:sourceOrganization v2.3

Type: owl:DatatypeProperty

Range: xsd:string

Organization that provided this record (e.g., "Kaiser Permanente", "Mayo Clinic"). Populated from FHIR meta.source or contained Organization reference during clinical record import. Used across all 11 CheckupShared record models for Health Map provenance display.

cascade:sourceDeviceName v2.3

Type: owl:DatatypeProperty

Range: xsd:string

Device or app that recorded this measurement (e.g., "Apple Watch Series 9", "Omron BP Monitor"). Populated from HealthKit HKSource contributing app/device name. Used across all 11 CheckupShared record models for Health Map provenance display.

Vocabulary Organization v1.3

cascade:subConcern

owl:AnnotationProperty

Classifies a vocabulary class by its functional role within a vocabulary. Values are vocabulary-specific documented conventions (e.g., 'summary', 'intake', 'analytics', 'identity', 'app-config', 'structural', 'deprecated'). Used for documentation generation, migration planning, and vocabulary organization.

Domain: owl:Class

Range: xsd:string

Reconciliation Properties v2.6

Properties used by the Cascade reconciliation pipeline to annotate merged records with provenance and conflict resolution metadata. Added when running cascade reconcile or via the reconciliation library.

The three source axes v3.5

A record carries three different answers to three different questions, and collapsing any two of them is a defect that has been measured on real pods.

AxisPropertyQuestion it answers
ORIGINcascade:sourceIdentity Which ORGANIZATION the record came from, as a canonical token that is the same whatever transport carried it. The only one of the three that may be used as a reconciliation key.
LABELclinical:sourceEHR What to CALL that organization on screen. Human-readable and source-worded, so two spellings of one organization are two labels.
INGESTIONcascade:sourceSystem How and when the data entered the Pod: the import batch. Never an origin.

The failure this distinction exists to end: a reconciler that keys “are these two records from the same source?” on the INGESTION axis answers yes for every pair on a single-batch Pod, so no duplicate is ever compared, and answers no for two exports of one organization, so one organization occupies two rows of any source view.

cascade:sourceIdentity v3.5

owl:DatatypeProperty

ORIGIN AXIS. The canonical, transport-independent identity of the organization a record came from. A FHIR export and a C-CDA document of the same health system carry the same value here, which is what makes it usable as a reconciliation key where a display label and an ingestion batch are not.

The value is a scheme-prefixed token, so a consumer can always tell how much the producer actually knew:

SchemeMeaning
org:{slug}An organization was derivable. {slug} is the normalized form below.
ns:{namespace}No organization was derivable, but the record's identifiers have an assigning authority: the FHIR server base URL, or the C-CDA <id> root OID.
transport:{label}LAST RESORT. Nothing named or located an organization, so the value restates cascade:sourceSystem, honestly prefixed. It is not an origin claim, and two transport: values mean “origin unknown” rather than “shared source”.

The slug normalization, which every transport must implement identically: take an organization name or the registrable domain of the source endpoint; for a domain, drop the public suffix and repeatedly strip any generic organization word forming a whole prefix or suffix of the remaining label; for a name, lowercase, fold diacritics, split on non-alphanumeric runs; then drop generic institution, specialty, legal-form and stopword tokens, and take the FIRST surviving token. Meridian Health System and meridianhealth.example both give org:meridian; Providence Health and Services Washington and Montana and providence.org both give org:providence.

Why the leading token and not all of them. The two failure directions are not symmetric. Collapsing two different organizations onto one identity suppresses comparisons between their records, so duplicates simply remain in the Pod: visible, and recoverable later. Splitting one organization across two identities lets records the organization deliberately kept apart be compared and merged, which destroys content. The normalization is therefore deliberately biased toward collapsing.

Range: xsd:string. Validation: cascade:SourceIdentityShape uses sh:targetSubjectsOf, so it checks the value wherever the property appears and never requires its presence. Pods written before v3.5 validate unchanged.

cascade:sourceSystem v2.4

owl:DatatypeProperty

INGESTION AXIS. The import batch a record entered the Pod through (e.g. "Apple Health export", "primary-care"), set by cascade convert --source-system <name>. It records HOW AND WHEN data arrived, NOT where it came from, and it must not be used as a source identity: one batch commonly carries records from several organizations, and one organization commonly arrives in many batches. Use cascade:sourceIdentity for origin.

Range: xsd:string

cascade:reconciliationStatus v2.4

owl:ObjectProperty

The outcome of reconciliation for this record. Value is a named individual URI from the cascade:ReconciliationStatus class:

Named IndividualMeaning
cascade:CanonicalUnique record — no matching record found across other source systems
cascade:MergedDeduplicated from two or more identical or near-identical source records
cascade:ConflictResolvedConflicting values resolved automatically via trust priority or merge strategy
cascade:UnresolvedConflictConflict could not be auto-resolved; flagged for manual clinical review
cascade:WithinSourceDuplicate v2.6Encounter-instance duplicate within same source system — suppressed during Pass 1 within-source deduplication

Range: cascade:ReconciliationStatus

cascade:mergedFrom v2.4

owl:ObjectProperty

Links a reconciled record to the source record URIs that were merged into it. Subproperty of prov:wasDerivedFrom for semantic interoperability. To find which systems contributed, follow these links and read cascade:sourceSystem on each referenced record.

Range: owl:Thing

Sub-property of: prov:wasDerivedFrom

cascade:conflictResolution v2.4

owl:ObjectProperty

The strategy used to resolve a conflict. Value is a named individual URI from the cascade:ConflictResolutionStrategy class:

Named IndividualMeaning
cascade:TrustPriorityRecord from the highest-trust source system is selected as canonical
cascade:MergeValuesCanonical record is built by taking the winner's fields and filling gaps from lower-trust sources
cascade:FlagUnresolvedConflict could not be automatically resolved; requires manual review

Range: cascade:ConflictResolutionStrategy

cascade:conflictField v2.4

owl:ObjectProperty

The predicate URI on which a conflict was detected (e.g. <https://ns.cascadeprotocol.org/health/v1#status>). Stored as a URI reference — use the full URI, not a prefixed name string.

Range: rdfs:Resource

cascade:conflictDescription v2.4 (removed v2.7)

owl:DatatypeProperty

Removed v2.7. Was informational prose describing conflicting values per source system. Replaced by cascade:conflictDetail structured blank node (v2.5); blank nodes carry an rdfs:comment for human-readable summaries.

Range: xsd:string

cascade:conflictDetail (v2.5)

Type: owl:ObjectProperty   Range: cascade:ConflictDetail

Links a reconciled record to a structured cascade:ConflictDetail blank node describing per-system conflict values. The blank node carries an rdfs:comment with a human-readable summary of the conflicting values.

cascade:ConflictDetail (class, v2.5)

Type: owl:Class

A structured representation of conflicting values for a single property across source systems. Used as a blank node linked from cascade:conflictDetail.

cascade:conflictFor (v2.5)

Type: owl:ObjectProperty   Range: rdfs:Resource

The predicate URI on which the conflict was detected (e.g. <https://ns.cascadeprotocol.org/health/v1#status>). Used within a cascade:ConflictDetail blank node.

cascade:systemValue (v2.5)

Type: owl:ObjectProperty

Links a cascade:ConflictDetail to a blank node representing one source system's value. Each participating system has its own cascade:systemValue blank node containing cascade:forSystem and rdf:value.

cascade:forSystem (v2.5)

Type: owl:DatatypeProperty   Range: xsd:string

The name of the source EHR system (e.g. "primary-care", "specialist") within a cascade:systemValue blank node.

Shared Preference Properties v1.3

Cross-app user preferences. These properties are used in /settings/shared/preferences.ttl for preferences that apply across all Cascade apps.

cascade:notificationsEnabled

owl:DatatypeProperty

Whether the user has enabled push notifications across Cascade apps.

Range: xsd:boolean

cascade:preferredUnits

owl:DatatypeProperty

User's preferred unit system: 'metric' or 'imperial'.

Range: xsd:string

Patient Profile v2.0

Health-specific patient demographics and related information. Complements the Solid foaf:Agent profile with structured health data fields for clinical summaries, intake forms, and care coordination.

cascade:PatientProfile v2.0

owl:Class

Health-specific patient demographics that complement the Solid foaf:Agent profile. Contains structured fields for date of birth, gender identity, biological sex, emergency contacts, address, pharmacy, and advance directives.

Subclass of: prov:Entity

cascade:dateOfBirth v2.0

owl:DatatypeProperty

Patient's date of birth.

Domain: cascade:PatientProfile

Range: xsd:date

cascade:genderIdentity v2.0

owl:DatatypeProperty

Patient's self-identified gender.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:biologicalSex v2.0

owl:DatatypeProperty

Patient's biological sex assigned at birth.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:ageGroup v2.0

owl:DatatypeProperty

Patient's age group classification.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:emergencyContactName v2.0

owl:DatatypeProperty

Name of the patient's emergency contact.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:emergencyContactRelationship v2.0

owl:DatatypeProperty

Relationship of the emergency contact to the patient (e.g., 'spouse', 'parent', 'sibling').

Domain: cascade:PatientProfile

Range: xsd:string

cascade:emergencyContactPhone v2.0

owl:DatatypeProperty

Phone number of the patient's emergency contact.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:hasAddress v2.0

owl:ObjectProperty

Links to a structured postal address.

Domain: cascade:PatientProfile

Range: cascade:Address

cascade:maritalStatus v2.0

owl:DatatypeProperty

Patient's marital status.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:raceEthnicity v2.0

owl:DatatypeProperty

Patient's race/ethnicity for demographic and clinical context.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:hasPreferredPharmacy v2.0

owl:ObjectProperty

Links to the patient's preferred pharmacy information.

Domain: cascade:PatientProfile

Range: cascade:PharmacyInfo

cascade:hasAdvanceDirectives v2.0

owl:ObjectProperty

Links to the patient's advance directive declarations.

Domain: cascade:PatientProfile

Range: cascade:AdvanceDirectives

Additional PatientProfile Properties v2.2

Properties emitted by the SDK PatientProfileSerializer but not previously defined in the ontology.

cascade:computedAge v2.2

owl:DatatypeProperty

Patient age in years, computed from dateOfBirth at serialization time.

Domain: cascade:PatientProfile

Range: xsd:integer

cascade:profileId v2.2

owl:DatatypeProperty

Unique identifier (UUID) for the patient profile instance. Used for traceability and deduplication.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:preferredLanguage v2.2

owl:DatatypeProperty

Patient's preferred language for medical communication. In the two-document Solid WebID Profile model, this should be emitted as dct:language in /profile/card.ttl. Defined for backward compatibility.

Domain: cascade:PatientProfile

Range: xsd:string

cascade:address v2.2

owl:ObjectProperty

Links an entity to an Address blank node. Used by PatientProfileSerializer.

Domain: cascade:PatientProfile

Range: cascade:Address

cascade:emergencyContact v2.2

owl:ObjectProperty

Links a PatientProfile to an EmergencyContact blank node.

Domain: cascade:PatientProfile

Range: cascade:EmergencyContact

cascade:advanceDirectives v2.2

owl:ObjectProperty

Links a PatientProfile to an AdvanceDirectives blank node.

Domain: cascade:PatientProfile

Range: cascade:AdvanceDirectives

cascade:preferredPharmacy v2.2

owl:ObjectProperty

Links a PatientProfile to a PharmacyInfo blank node.

Domain: cascade:PatientProfile

Range: cascade:PharmacyInfo

Supporting Classes

cascade:Address v2.0

owl:Class

Structured postal address. Used by cascade:PatientProfile and cascade:PharmacyInfo via the cascade:hasAddress property.

cascade:streetAddress v2.0

owl:DatatypeProperty

Street address line (e.g., '123 Main St, Apt 4'). Simplified alias of cascade:addressLine for flat serialization patterns.

Domain: cascade:Address

Range: xsd:string

cascade:city v2.0

owl:DatatypeProperty

City or locality name. Simplified alias of cascade:addressCity for flat serialization patterns.

Domain: cascade:Address

Range: xsd:string

cascade:state v2.0

owl:DatatypeProperty

State, province, or region. Simplified alias of cascade:addressState for flat serialization patterns.

Domain: cascade:Address

Range: xsd:string

cascade:postalCode v2.0

owl:DatatypeProperty

Postal or ZIP code. Simplified alias of cascade:addressPostalCode for flat serialization patterns.

Domain: cascade:Address

Range: xsd:string

cascade:country v2.0

owl:DatatypeProperty

Country name or ISO 3166-1 code. Simplified alias of cascade:addressCountry for flat serialization patterns.

Domain: cascade:Address

Range: xsd:string

FHIR-Aligned Address Properties v2.2

These properties mirror the FHIR Address datatype fields used by the SDK Address struct. The simpler properties above are retained as aliases for backward compatibility.

cascade:addressUse v2.2

owl:DatatypeProperty

Purpose of the address: home, work, temp, old. Aligns with FHIR Address.use.

Domain: cascade:Address

Range: xsd:string

cascade:addressType v2.2

owl:DatatypeProperty

Type of address: postal, physical, both. Aligns with FHIR Address.type.

Domain: cascade:Address

Range: xsd:string

cascade:addressText v2.2

owl:DatatypeProperty

Full address as a single text string. Aligns with FHIR Address.text.

Domain: cascade:Address

Range: xsd:string

cascade:addressLine v2.2

owl:DatatypeProperty

Street address line. Repeatable for multi-line addresses. Aligns with FHIR Address.line.

Domain: cascade:Address

Range: xsd:string

cascade:addressCity v2.2

owl:DatatypeProperty

City name. FHIR-aligned equivalent of cascade:city.

Domain: cascade:Address

Range: xsd:string

cascade:addressDistrict v2.2

owl:DatatypeProperty

District or county. Aligns with FHIR Address.district.

Domain: cascade:Address

Range: xsd:string

cascade:addressState v2.2

owl:DatatypeProperty

State or province. FHIR-aligned equivalent of cascade:state.

Domain: cascade:Address

Range: xsd:string

cascade:addressPostalCode v2.2

owl:DatatypeProperty

Postal or ZIP code. FHIR-aligned equivalent of cascade:postalCode.

Domain: cascade:Address

Range: xsd:string

cascade:addressCountry v2.2

owl:DatatypeProperty

Country name or ISO code. FHIR-aligned equivalent of cascade:country.

Domain: cascade:Address

Range: xsd:string

cascade:PharmacyInfo v2.0

owl:Class

Information about the patient's preferred pharmacy. Reuses cascade:hasAddress to link to a structured cascade:Address.

cascade:pharmacyName v2.0

owl:DatatypeProperty

Name of the pharmacy (e.g., 'CVS Pharmacy', 'Walgreens').

Domain: cascade:PharmacyInfo

Range: xsd:string

cascade:pharmacyPhone v2.0

owl:DatatypeProperty

Phone number of the pharmacy.

Domain: cascade:PharmacyInfo

Range: xsd:string

cascade:pharmacyAddress v2.2

owl:DatatypeProperty

Pharmacy address as a single text string. Simplified alternative to using a nested cascade:Address blank node.

Domain: cascade:PharmacyInfo

Range: xsd:string

cascade:EmergencyContact v2.2

owl:Class

A patient's emergency contact person. Used as a blank node within cascade:PatientProfile.

cascade:contactName v2.2

owl:DatatypeProperty

Full name of a contact person.

Domain: cascade:EmergencyContact

Range: xsd:string

cascade:contactRelationship v2.2

owl:DatatypeProperty

Relationship of the contact to the patient: spouse, parent, child, sibling, partner, friend, caregiver, other.

Domain: cascade:EmergencyContact

Range: xsd:string

cascade:contactPhone v2.2

owl:DatatypeProperty

Phone number for a contact person. Used within EmergencyContact blank nodes and also for general contact use on PatientProfile.

Range: xsd:string

cascade:AdvanceDirectives v2.0

owl:Class

Advance directive declarations including living will, power of attorney, and DNR status.

cascade:hasLivingWill v2.0

owl:DatatypeProperty

Whether the patient has a living will on file.

Domain: cascade:AdvanceDirectives

Range: xsd:boolean

cascade:hasPowerOfAttorney v2.0

owl:DatatypeProperty

Whether the patient has designated a healthcare power of attorney.

Domain: cascade:AdvanceDirectives

Range: xsd:boolean

cascade:hasDNR v2.0

owl:DatatypeProperty

Whether the patient has a Do Not Resuscitate order.

Domain: cascade:AdvanceDirectives

Range: xsd:boolean

cascade:advanceDirectiveNotes v2.0

owl:DatatypeProperty

Free-text notes or additional details about the patient's advance directives.

Domain: cascade:AdvanceDirectives

Range: xsd:string

Usage Example

@prefix cascade: <https://ns.cascadeprotocol.org/core/v1#> .
@prefix pots: <https://ns.cascadeprotocol.org/pots/v1#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<#pots-check-123> a pots:POTSCheckResult ;
    cascade:schemaVersion "1.2" ;
    cascade:dataProvenance cascade:ConsumerGenerated ;
    prov:wasAttributedTo <https://id.cascadeprotocol.org/users/abc123> ;
    prov:wasGeneratedBy [
        a prov:Activity ;
        prov:wasAssociatedWith <https://id.cascadeprotocol.org/users/abc123> ;
        prov:startedAtTime "2025-10-31T10:00:00Z"^^xsd:dateTime
    ] ;
    pots:date "2025-10-31T10:00:00Z"^^xsd:dateTime ;
    pots:protocol "nasaLean" .

W3C PROV-O Integration

The Cascade Protocol extends the W3C PROV-O (Provenance Ontology) for comprehensive data lineage tracking:

  • All health data entities are prov:Entity instances
  • cascade:creatorWebID links to prov:Agent (the user)
  • Generation activities tracked via prov:wasGeneratedBy
  • Temporal metadata captured with prov:startedAtTime

Design Principles

  • Modularity: Core vocabulary is stable; domain vocabularies evolve independently
  • Standards-based: Built on W3C RDF, OWL, and PROV-O recommendations
  • Solid-compatible: Designed for Solid Pod storage with WebID-based access control
  • Future-proof: New health apps can extend without breaking existing data

Pod Export Manifest v3.4

A pod export carries a manifest.ttl describing what the export contains. Before v3.4 every term in that file was undefined vocabulary: a consumer could parse a manifest, but nothing said what its terms meant and no shape checked it. v3.4 defines all 32 terms and shapes the three classes. The change is additive — no serializer emits anything different and no existing manifest is rewritten.

Two of the three classes are expressed in ratified standards rather than novel Cascade terms. A pod export is a published dataset with a title, description, creation date and publisher, which DCAT 3 already standardises; a record summary is a statistical description of a dataset subset, which is what VoID is for. Inventing a parallel set of terms for either would have been novelty for its own sake.

cascade:ExportManifest

owl:Class

Provenance and completeness metadata for a complete pod export: when it was generated, which schema versions it uses, how many records of each kind it contains, and which provenance layers are represented. Consumers should read this before processing individual resources.

Subclass of: dcat:Dataset, prov:Entity

Properties: cascade:patientProfileVersion, cascade:provenanceLayers, cascade:clinicalSummary, cascade:wellnessSummary, cascade:deviceSources, cascade:interactionScenarios

cascade:RecordSummary

owl:Class

Per-domain record counts for one partition of a pod export. Each count property is declared rdfs:subPropertyOf void:entities and paired with the void:class it counts, so a VoID-aware consumer reads Cascade record counts with no Cascade-specific code.

Subclass of: void:Dataset

Counts: cascade:conditionCount, cascade:medicationCount, cascade:allergyCount, cascade:labResultCount, cascade:immunizationCount, cascade:supplementCount, cascade:coverageCount

Wellness day counts: cascade:vitalSignDays, cascade:heartRateDays, cascade:bloodPressureDays, cascade:activityDays, cascade:sleepDays. These describe coverage rather than record counts and are not void:entities subproperties.

cascade:InteractionScenario

owl:Class

A clinically significant interaction that can only be detected by correlating resources of differing provenance — for example an EHR-prescribed drug against a self-reported supplement against a lab value. Kept Cascade-specific and deliberately novel: no ratified vocabulary models cross-provenance correlation as a first-class thing.

Subclass of: prov:Entity

Properties: cascade:involvedResources, cascade:severity, cascade:requiresCrossProvenance

v3.4 also defines the reading-level terms cascade:date, cascade:sampleCount and cascade:loincCode, which are emitted on every history-container entry and are constrained by the health v2.5 daily-snapshot shapes, plus cascade:sourceType, cascade:dataTypes, cascade:version and cascade:notes.

SHACL Validation Shapes

Validation shapes for this vocabulary are defined in core.shapes.ttl (v1.1).

Shapes defined:

  • cascade:PatientProfileShape — Validates PatientProfile instances with required demographics fields
  • cascade:AddressShape — Validates Address blank nodes with street, city, state, postal code, and country
  • cascade:EmergencyContactShape — Validates EmergencyContact blank nodes with name, relationship, and phone
  • cascade:PharmacyInfoShape — Validates PharmacyInfo blank nodes with pharmacy name and phone
  • cascade:AdvanceDirectivesShape — Validates AdvanceDirectives blank nodes with living will, POA, and DNR flags
  • cascade:ExportManifestShape — Validates pod export manifests (v1.1)
  • cascade:RecordSummaryShape — Validates per-partition record summaries (v1.1)
  • cascade:InteractionScenarioShape — Validates cross-provenance interaction entries (v1.1)
  • cascade:SourceIdentityShape — Validates the value of cascade:sourceIdentity wherever it appears; open-world, so absence is not a finding (v1.5)

Changelog

Version 3.6 (2026-08-14)

  • Added cascade:dataAbsentReason: why a record's primary VALUE is absent, with exactly the semantics of FHIR R4 Observation.dataAbsentReason and bound to the 15 codes of data-absent-reason. A C-CDA document distinguishes nullFlavor UNK, NAV, NASK and ASKU, and an importer that drops all four writes one indistinguishable blank, so a reader cannot tell a test that was never ordered from one whose result is pending.
  • The full HL7 v3 NullFlavor to data-absent-reason mapping an importer must implement is stated on the property. Binding to data-absent-reason rather than to NullFlavor is deliberate: this vocabulary already cites it, its 15 codes are all selectable where NullFlavor marks NI, UNK, OTH and INV abstract, and FHIR is the transport both converter paths read.
  • Stated the NORMATIVE canonical form of a multi-valued identity input on cascade:cascadeUri. Since four code fields became 0..*, an identifier hashed over an unordered field is not stable: two exports of one record listing the same codings in a different order would mint two identifiers and the record would silently split in two. The rule is dedupe, sort by Unicode code point, join with a fixed separator (U+002C recommended and required of new implementations), and a one-element sequence canonicalizes to the bare scalar so no identifier already written moves.
  • Three invariants are normative independently of the separator and are what the conformance vectors check: order independence, scalar agreement, duplicate independence. The scope limit is as load-bearing as the rule: it applies to inputs that are SETS and must never be applied to an input whose source order carries meaning.
  • core.shapes.ttl v1.6 adds cascade:DataAbsentReasonShape, an open-world sh:targetSubjectsOf shape, so every pod written before v3.6 validates unchanged. Raw NullFlavor codes are deliberately rejected: an absence must not have two encodings.
  • No class or property removed, renamed or deprecated.

Version 3.5 (2026-08-09)

  • Added cascade:sourceIdentity, the ORIGIN axis: a canonical, transport-independent identity for the organization a record came from, scheme-prefixed org: / ns: / transport: so a consumer can see how much the producer actually knew.
  • Stated the three source axes explicitly, because two of them were already here and being used interchangeably. cascade:sourceSystem's definition now says what it is NOT: the INGESTION batch, never an origin, and never a reconciliation key. clinical:sourceEHR is unchanged and remains the display LABEL.
  • The slug normalization both transports must implement is stated on the property itself, and is deliberately biased toward collapsing two organizations rather than splitting one.
  • core.shapes.ttl v1.5 adds cascade:SourceIdentityShape, an open-world sh:targetSubjectsOf shape. Absence of the property is not a finding at any severity, so every pod written before v3.5 validates unchanged; the ratchet to Warning and then Violation is written into the ontology changelog.
  • No class or property removed, renamed or deprecated.

Version 3.4 (2026-08-03)

  • Defined the pod export manifest vocabulary. 32 cascade: terms that a conforming pod export emits had no definition in this file at all; all 32 are now defined, so a manifest is describable rather than only parseable.
  • cascade:ExportManifest is rdfs:subClassOf dcat:Dataset (DCAT 3).
  • cascade:RecordSummary is rdfs:subClassOf void:Dataset (VoID), with its per-domain count properties declared rdfs:subPropertyOf void:entities and paired with the void:class each counts.
  • cascade:InteractionScenario is kept as genuinely novel — no ratified vocabulary covers cross-provenance correlation.
  • Also defined the reading-level terms cascade:date, cascade:sampleCount and cascade:loincCode, emitted on every history-container entry and constrained by the health v2.5 daily-snapshot shapes.
  • core.shapes.ttl v1.1 shapes all three manifest classes.

Version 3.3 (2026-06-16)

  • Cascade Workbench support.
  • Added cascade:AIAsserted provenance leaf (subclass of cascade:ConsumerGenerated) for ungrounded content surfaced by a general-purpose AI assistant — distinct from cascade:AIExtracted (clinically grounded) and cascade:EHRVerified; must be evidence-checked before reliance.
  • Added cascade:ProxyAgent (subclass of prov:Agent) for a person operating a patient's Pod on the patient's behalf, closing the caregiver-proxy gap.
  • Added 6 ProxyAgent properties: cascade:actsForPatient (subproperty of prov:actedOnBehalfOf), cascade:proxyWebID, cascade:proxyRelationship, cascade:proxyScope, cascade:proxyGrantedAt, cascade:proxyRevokedAt.

Version 3.2 (2026-05-06)

  • Forward-reference closure for the advisory applier.
  • Added cascade:appliedTriplesCount (DatatypeProperty, range xsd:nonNegativeInteger, domain cascade:AdvisoryApplicationActivity) recording triples inserted by a single advisory application — auditable verification of CAP profile constraint C5 (≤ 64 inserted triples per match).

Version 3.1 (2026-05-05)

  • Genomics & Advisory provenance.
  • Added cascade:AdvisoryApplicationActivity (prov:Activity subclass) for recording application of a Cascade Advisory Patch to a Pod (advisory and matched record linked via prov:used).
  • Added cascade:AIGenerationActivity (prov:Activity subclass), sibling of cascade:AIExtractionActivity, for LLM-generated narrative chunks; adds cascade:promptVersion and cascade:generationTemperature.
  • Added cascade:trigger ObjectProperty (range cascade:GenerationTrigger) with three named individuals: cascade:InitialGeneration, cascade:RegenerationAfterReclassification, cascade:AudienceRetargeting.

Version 3.0 (2026-03-28)

  • Added cascade:HealthRecord abstract superclass for all health data records.
  • Added cascade:AIExtractionActivity (PROV-O Activity for AI/NLP extraction passes) with cascade:extractionConfidence, cascade:extractionModel, cascade:sourceNarrativeSection, cascade:requiresUserReview.
  • Added cascade:AIDiscardedExtraction (audit record for discarded extraction candidates) with cascade:discardReason.
  • Added cascade:SocialHistoryConsent (42 CFR Part 2 consent record) with cascade:consentScope, cascade:consentGrantedAt, cascade:consentRevokedAt.

Version 2.9 (2026-03-12)

  • Added conflict-resolution classes cascade:UserResolution and cascade:PendingConflict with supporting properties (conflictId, resolution, keptRecord, discardedRecords, userNote, candidateRecords, detectedAt, autoResolved).
  • Added document-provenance properties cascade:documentType, cascade:sectionCode, cascade:sourceRecordId.

Version 2.8 (2026-03-12)

  • Added cascade:layerPromotionStatus ObjectProperty and cascade:LayerPromotionStatusValue class for FHIR conversion support
  • Added named individuals cascade:FullyMapped and cascade:PendingLayerTwoPromotion
  • Added cascade:fhirJson DatatypeProperty (xsd:string, inline FHIR JSON for passthrough records)
  • Added cascade:fhirResourceType DatatypeProperty (xsd:string, originating FHIR resource type)
  • Added cascade:sourceRecordDate DatatypeProperty (xsd:dateTime, primary date from source FHIR resource)

Version 2.7 (2026-03-12)

  • Removed cascade:conflictDescription (deprecated since v2.5). cascade:conflictDetail blank nodes now carry an rdfs:comment with a human-readable conflict summary.

Version 2.6 (2026-03-11)

  • Added within-source deduplication vocabulary (Phase 6 of reconciliation pipeline)
  • New named individual: cascade:WithinSourceDuplicate (class cascade:ReconciliationStatus) — represents encounter-instance duplicate records suppressed during Pass 1 within-source deduplication before cross-system matching

Version 2.5 (2026-03-11)

  • Added structured conflict representation vocabulary (Phase 5 of reconciliation pipeline)
  • New class: cascade:ConflictDetail — structured blank node for per-system conflict values
  • New properties: cascade:conflictDetail (ObjectProperty, links record to ConflictDetail), cascade:conflictFor (ObjectProperty, the conflicting predicate URI), cascade:systemValue (ObjectProperty, per-system value blank node), cascade:forSystem (DatatypeProperty, system name string)
  • Deprecated cascade:conflictDescription (informational prose string, replaced by cascade:conflictDetail structured blank node — removed in v2.7)
  • Added rdf: prefix to serializer output for rdf:value and rdf:type within blank nodes

Version 2.4 (2026-03-11)

  • Added reconciliation vocabulary for multi-system EHR data merging
  • Properties: cascade:sourceSystem (DatatypeProperty, EHR origin tag), cascade:reconciliationStatus (ObjectProperty), cascade:mergedFrom (ObjectProperty, subPropertyOf prov:wasDerivedFrom), cascade:conflictResolution (ObjectProperty), cascade:conflictField (ObjectProperty, stores full predicate URI), cascade:conflictDescription (DatatypeProperty, informational prose — removed v2.7)
  • Named individuals — cascade:ReconciliationStatus class: cascade:Canonical, cascade:Merged, cascade:ConflictResolved, cascade:UnresolvedConflict
  • Named individuals — cascade:ConflictResolutionStrategy class: cascade:TrustPriority, cascade:MergeValues, cascade:FlagUnresolved
  • Supports the cascade reconcile command added in CLI v0.2.5 and the --source-system flag on cascade convert; cascade pod import added in v0.3.0

Version 2.3 (2026-02-22)

  • Added cascade:sourceOrganization — organization that provided a record (e.g., "Kaiser Permanente"). Populated from FHIR meta.source or contained Organization reference during clinical import.
  • Added cascade:sourceDeviceName — device or app that recorded a measurement (e.g., "Apple Watch Series 9"). Populated from HealthKit HKSource contributing app/device name.
  • Both properties used across all 11 CheckupShared record models for Health Map provenance display. Part of Health Map v3 Pre-Phase Track A (Task A4).

Version 2.2 (2026-02-18)

  • ONT1: Added 9 FHIR-aligned Address properties: addressUse, addressType, addressText, addressLine, addressCity, addressDistrict, addressState, addressPostalCode, addressCountry
  • Updated existing simple Address properties (streetAddress, city, state, postalCode, country) as simplified aliases
  • ONT2: Added PatientProfile properties: computedAge, profileId, preferredLanguage, pharmacyAddress
  • Added cascade:EmergencyContact class with contactName, contactRelationship, contactPhone
  • Added object properties: emergencyContact, advanceDirectives, preferredPharmacy, address (blank-node linking variants)
  • Part of Schema Refactoring Plan Phase 3.5

Version 2.1 (2026-02-17)

  • Added cascade:addedInSchemaVersion annotation property for recording when a data element was introduced
  • Added cascade:cascadeUri datatype property for stable identifier URIs across vocabularies
  • Part of Schema Refactoring Plan Phase 3 (PF1-R)

Version 2.0 (2026-02-17)

  • Added cascade:PatientProfile class for health-specific patient demographics, complementing Solid foaf:Agent profile
  • Added cascade:Address class with 5 properties: streetAddress, city, state, postalCode, country
  • Added cascade:PharmacyInfo class with 2 properties: pharmacyName, pharmacyPhone (reuses hasAddress)
  • Added cascade:AdvanceDirectives class with 4 properties: hasLivingWill, hasPowerOfAttorney, hasDNR, advanceDirectiveNotes
  • Added 12 PatientProfile properties: dateOfBirth, genderIdentity, biologicalSex, ageGroup, emergencyContactName, emergencyContactRelationship, emergencyContactPhone, hasAddress, maritalStatus, raceEthnicity, hasPreferredPharmacy, hasAdvanceDirectives
  • Added foaf: and vcard: prefix declarations

Version 1.3 (2026-02-17)

  • Added cascade:subConcern annotation property for classifying vocabulary classes by functional role
  • Added shared preference properties: notificationsEnabled, preferredUnits
  • Part of Schema Refactoring Plan Phase 1 (WS2 + WS5)

Version 1.2 (2026-02-10)

  • Promoted ConsumerGenerated/ClinicalGenerated from OWL individuals to owl:Class subclasses of DataProvenance
  • Added 6 DataProvenance subclasses:
    • Consumer: DeviceGenerated, SelfReported, ConsumerWellness
    • Clinical: EHRVerified, ScannedDocument, AIExtracted

Version 1.1 (2026-02-01)

  • Added DataSource class for device/app/system identity with reliability tiers

Version 1.0 (2025-10-31)

  • Initial release: schema versioning, data provenance, identity (creatorWebID), W3C PROV-O alignment