For App Developers

Data Modeling Cookbook

This guide shows how the Global.Church ontology models core entity types. Each example includes Turtle (the native RDF syntax) and JSON-LD (for developers more comfortable with JSON).

The ontology namespace is https://ontology.global.church/core# (prefix gc:). All domain classes descend from W3C PROV-O types: prov:Agent, prov:Activity, or prov:Entity. Reference data uses SKOS without PROV-O parentage.

Modeling an Organization

A gc:Organization is a prov:Agent -- an entity that can act, make decisions, and bear responsibility. Organizations include churches, mission agencies, denominations, and networks.

Every organization must have a name and at least one organization type. Other properties (city, state, website, belief classification) are optional.

Turtle

Code
 
@prefix gc: <https://ontology.global.church/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<https://data.global.church/org/example-church>
  a gc:Organization ;
  rdfs:label "Example Community Church" ;
  gc:orgName "Example Community Church" ;
  gc:hasOrganizationType gc:OrgTypeChurch ;
  gc:city "Denver" ;
  gc:state "CO" ;
  gc:country "US" ;
  gc:hasBeliefClassification gc:BeliefProtestant ;
  gc:hasDenominationClassification gc:DenomBaptist .

JSON-LD

Code
 
{
  "@context": {
    "gc": "https://ontology.global.church/core#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#"
  },
  "@id": "https://data.global.church/org/example-church",
  "@type": "gc:Organization",
  "rdfs:label": "Example Community Church",
  "gc:orgName": "Example Community Church",
  "gc:hasOrganizationType": { "@id": "gc:OrgTypeChurch" },
  "gc:city": "Denver",
  "gc:state": "CO",
  "gc:country": "US",
  "gc:hasBeliefClassification": { "@id": "gc:BeliefProtestant" },
  "gc:hasDenominationClassification": { "@id": "gc:DenomBaptist" }
}

Key Points

rdfs:label is the required display name (enforced by SHACL).
gc:hasOrganizationType links to a SKOS concept from the OrganizationTypeScheme (Church, MissionAgency, Denomination, Network, etc.).
Classification properties (gc:hasBeliefClassification, gc:hasDenominationClassification) link to SKOS concepts in the production vocabularies graph.
Country uses ISO 3166-1 alpha-2 codes (e.g., "US", "IN", "NG").

Modeling a Church

A church body is dual-typed: it carries both gc:Organization (with gc:hasOrganizationType gc:OrgTypeChurch) and gc:EkklesiaCommunity — the persistent gathered community of believers. gc:EkklesiaCommunity is a sibling of gc:PeopleGroupCommunity under the shared gc:Community taxonomy (it is not a subclass of gc:Organization); the two types coexist on the same URI because a gathered church is both an organization-as-actor and a community-on-the-ground. The Ekklesia typing is inferred automatically from gc:OrgTypeChurch, so most data sources only need to assert the Organization side and let inference produce the Ekklesia triples.

A church body must declare one gc:hasEkklesiaForm (e.g. gc:FormLocalChurch, gc:FormHouseChurch, gc:FormRegionalChurch, gc:FormApostolicBand, gc:FormMissionalOrder) and realize at least one gc:EkklesiaSegment — the scoped slice through which engagement attestations and per-scope assessments attach. A typical single-site local church realizes one gc:Ekk-LocalBody-scoped segment.

Turtle

Code
 
@prefix gc: <https://ontology.global.church/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://data.global.church/org/calvary-church-denver>
  a gc:Organization, gc:EkklesiaCommunity ;
  rdfs:label "Calvary Church" ;
  gc:orgName "Calvary Church" ;
  gc:hasOrganizationType gc:OrgTypeChurch ;
  gc:hasEkklesiaForm gc:FormLocalChurch ;
  gc:realizesEkklesiaSegment <https://data.global.church/org/calvary-church-denver/segment/local-body> ;
  gc:city "Denver" ;
  gc:state "CO" ;
  gc:country "US" ;
  gc:website "https://calvarychurch.com"^^xsd:anyURI ;
  gc:isMultiCampus false ;
  gc:servicesInfo "Sunday 9:00am & 11:00am" ;
  gc:hasBeliefClassification gc:BeliefProtestant ;
  gc:hasDenominationClassification gc:DenomNonDenominational ;
  gc:servesPeopleGroup <https://data.global.church/jp/pg/100004-US> .

<https://data.global.church/org/calvary-church-denver/segment/local-body>
  a gc:EkklesiaSegment ;
  gc:hasEkklesiaScope gc:Ekk-LocalBody .

Key Points

The body carries a gc:Organization, gc:EkklesiaCommunity together — gc:EkklesiaCommunity is a subclass of gc:Community, not of gc:Organization. Queries for ?x a gc:Organization still return church bodies (because the Organization typing is asserted directly), and queries for ?x a gc:EkklesiaCommunity return only gathered bodies.
gc:hasEkklesiaForm selects from gc:EkklesiaFormScheme and is required by SHACL. Forms cover the structural variety of church bodies: local church, house church, regional / multi-site church, apostolic band, missional order. The Form is auto-defaulted to gc:FormLocalChurch for OrgTypeChurch bodies that don't assert one.
gc:realizesEkklesiaSegment links the body to a gc:EkklesiaSegment whose gc:hasEkklesiaScope says what slice of the body is in view (the whole body, a single campus, a country-scoped slice of a network). Engagement attestations and segment-scoped assessments hang off the segment, not the body directly.
gc:servesPeopleGroup links a church to the people groups it intentionally serves (distinct from gc:targetsPeopleGroup, which is automated geographic association).
Non-gathered organizations (mission agency, denomination, network, parachurch, coalition) stay as plain gc:Organization carrying their own type tag — they get no Ekklesia facets, no segment, no Form, no Lifecycle.

Multi-site: Campus-as-Segment

A multi-site church is not modeled as several churches with a parent — it is one gc:EkklesiaCommunity body that realizes one rollup segment plus one gc:Ekk-LocalCampus-scoped segment per campus. Each campus-segment carries gc:campusName and gc:meetsAt a gc:Location venue (the precise physical address where that campus gathers).

Code
 
<https://data.global.church/org/example-multisite>
  a gc:Organization, gc:EkklesiaCommunity ;
  gc:hasOrganizationType gc:OrgTypeChurch ;
  gc:hasEkklesiaForm gc:FormRegionalChurch ;
  gc:isMultiCampus true ;
  gc:realizesEkklesiaSegment
    <https://data.global.church/org/example-multisite/segment/in-country> ,
    <https://data.global.church/org/example-multisite/campus/north> ,
    <https://data.global.church/org/example-multisite/campus/south> .

<https://data.global.church/org/example-multisite/campus/north>
  a gc:EkklesiaSegment ;
  gc:hasEkklesiaScopeType gc:Ekk-LocalCampus ;
  gc:campusName "North Campus" ;
  gc:meetsAt <https://data.global.church/org/example-multisite/campus/north/venue> ;
  gc:subEkklesiaSegmentOf <https://data.global.church/org/example-multisite/segment/in-country> .

One directory record, N campuses, N venues — the rollup segment carries the cross-campus identity, the campus-segments carry the per-location detail. See the Ekklesia Model reference for the full pattern.

Church planting as a first-class lineage

A daughter body points at its sender via gc:wasSentFrom. For lightweight planting records that's all you need, and multi-hop ancestry walks via the SPARQL property-path gc:wasSentFrom+. When the sending event itself is the unit of record — with multiple participants (sending church, coaching parachurch, denominational underwriter) playing distinct roles — promote it to an n-ary gc:Commissioning activity with one gc:CommissioningParticipation per participant, each carrying its gc:organizationRole from gc:OrganizationRoleScheme (gc:RoleLead for the canonical sender, gc:RolePartner for coaches, etc.). The binary gc:wasSentFrom shortcut is materialized from the gc:Commissioning automatically, so lineage queries don't have to walk the n-ary structure. See Ekklesia Model → Commissioning for the full pattern.

Modeling an Engagement Attestation

A gc:EngagementAttestation is a dated declarative claim that an organization is engaging a particular scope. It is a prov:Entity — the fact of the claim — distinct from the underlying activity that produced it. Attestations are what the POST /v0/engagement-claims/submit endpoint creates.

An attestation carries its claiming organization (gc:claimingOrganization), the scope (gc:hasEngagementAccelerator, gc:claimedPeopleGroupName, gc:claimedCountryName), an gc:attestationStatus, and a gc:claimDate.

Turtle

Code
 
@prefix gc: <https://ontology.global.church/core#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://data.global.church/engagement-claims/wycliffe-quechua-2024>
  a gc:EngagementAttestation ;
  gc:claimingOrganization <https://data.global.church/org/wycliffe> ;
  gc:attestationStatus    gc:AttestationStatusActive ;
  gc:claimDate            "2024-01-15"^^xsd:date ;
  gc:hasEngagementAccelerator gc:FnBibleTranslation ;
  gc:claimedPeopleGroupName   "Quechua, Cusco" ;
  gc:claimedCountryName       "Peru" ;
  gc:claimDescription         "New Testament translation in progress." ;
  prov:wasAttributedTo        <mailto:[email protected]> .

<https://data.global.church/org/wycliffe>
  a gc:Organization ;
  gc:orgName "Wycliffe Bible Translators" .

JSON-LD

Code
 
{
  "@context": {
    "gc": "https://ontology.global.church/core#",
    "prov": "http://www.w3.org/ns/prov#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "https://data.global.church/engagement-claims/wycliffe-quechua-2024",
  "@type": "gc:EngagementAttestation",
  "gc:claimingOrganization": { "@id": "https://data.global.church/org/wycliffe" },
  "gc:attestationStatus":    { "@id": "gc:AttestationStatusActive" },
  "gc:claimDate":            { "@value": "2024-01-15", "@type": "xsd:date" },
  "gc:hasEngagementAccelerator": { "@id": "gc:FnBibleTranslation" },
  "gc:claimedPeopleGroupName":   "Quechua, Cusco",
  "gc:claimedCountryName":       "Peru",
  "gc:claimDescription":         "New Testament translation in progress."
}

Key points

An attestation is a claim, not an activity. The same organization may file multiple attestations over time as scope or status changes.
gc:hasEngagementAccelerator may take either an accelerator-level concept (e.g. gc:AccPrayer) or a function-level concept (e.g. gc:FnBibleTranslation). See Engagement Accelerators.
gc:fulfillsCommitment may optionally link the attestation to a prior gc:FulfillmentCommitment. See Needs & Commitments.
An attestation can be filed via the API (POST /v0/engagement-claims/submit) or contributed as Turtle through a partner integration.

Modeling a People Group

A gc:PeopleGroup is a source-defined classification concept naming a people group under a governing scheme (Joshua Project, IMB, ROP3). Joshua Project bridge URIs follow the ROP3 + ISO country pattern (e.g. 110532-IN is the Shaikh classification scoped to India), so the example below combines classification properties and country-scoped assessment data on a single PG resource. Assessment metrics use the 3-block pattern: PeopleGroup + gc:Assessment + gc:AssessmentResult.

Turtle

Code
 
@prefix gc: <https://ontology.global.church/core#> .
@prefix jp: <https://ontology.global.church/joshuaproject#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# Block 1: People Group (identity and classification)
<https://data.global.church/jp/pg/110532-IN>
  a gc:PeopleGroup ;
  gc:peopleName "Shaikh" ;
  gc:country "IN" ;
  jp:population 172572000 ;
  jp:continent "Asia" ;
  jp:affinityBloc "South Asian Peoples" ;
  jp:peopleCluster "Shaikh" ;
  gc:hasPeopleClassification <https://data.global.church/his/rop3/110532> ;
  gc:hasLanguageClassification <https://data.global.church/his/rol/urd> ;
  gc:hasReligionClassification <https://data.global.church/his/ror/M> ;
  gc:hasGeographyClassification <https://data.global.church/his/rog/IN> ;
  owl:sameAs <https://joshuaproject.net/people_groups/110532/IN> .

# Block 2: Assessment (provenance — who assessed, when)
<https://data.global.church/jp/assessment/110532-IN>
  a gc:Assessment ;
  gc:assessesPeopleGroup <https://data.global.church/jp/pg/110532-IN> ;
  prov:wasAssociatedWith <https://data.global.church/org/joshua-project> ;
  prov:generatedAtTime "2026-01-15T00:00:00Z"^^xsd:dateTime .

# Block 3: Assessment Result (metric values)
<https://data.global.church/jp/result/110532-IN>
  a gc:AssessmentResult ;
  gc:resultForPeopleGroup <https://data.global.church/jp/pg/110532-IN> ;
  prov:wasGeneratedBy <https://data.global.church/jp/assessment/110532-IN> ;
  jp:jpScale 1 ;
  jp:percentChristian 0.0 ;
  jp:leastReached true ;
  jp:frontier true ;
  jp:primaryReligion "Islam" .

JSON-LD

Code
 
[
  {
    "@context": {
      "gc": "https://ontology.global.church/core#",
      "jp": "https://ontology.global.church/joshuaproject#",
      "prov": "http://www.w3.org/ns/prov#",
      "owl": "http://www.w3.org/2002/07/owl#",
      "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@id": "https://data.global.church/jp/pg/110532-IN",
    "@type": "gc:PeopleGroup",
    "gc:peopleName": "Shaikh",
    "gc:country": "IN",
    "jp:population": 172572000,
    "jp:continent": "Asia",
    "gc:hasPeopleClassification": {
      "@id": "https://data.global.church/his/rop3/110532"
    },
    "gc:hasLanguageClassification": {
      "@id": "https://data.global.church/his/rol/urd"
    },
    "gc:hasReligionClassification": {
      "@id": "https://data.global.church/his/ror/M"
    },
    "owl:sameAs": {
      "@id": "https://joshuaproject.net/people_groups/110532/IN"
    }
  },
  {
    "@id": "https://data.global.church/jp/result/110532-IN",
    "@type": "gc:AssessmentResult",
    "gc:resultForPeopleGroup": {
      "@id": "https://data.global.church/jp/pg/110532-IN"
    },
    "jp:jpScale": 1,
    "jp:percentChristian": 0.0,
    "jp:leastReached": true,
    "jp:frontier": true
  }
]

Key Points

Identity vs. assessment separation. Descriptive properties (name, population, continent, language) live on the PeopleGroup. Assessment metrics (JP Scale, percent Christian, least reached) live on the AssessmentResult. This separation exists because different organizations can assess the same people group differently.
HIS classification links. Four classification properties connect the people group to HIS registry SKOS concepts: gc:hasPeopleClassification (ROP3), gc:hasLanguageClassification (ROL), gc:hasReligionClassification (ROR), gc:hasGeographyClassification (ROG). These serve as the cross-dataset join keys.
3-block pattern. Both Joshua Project and IMB data follow this same structure. To query assessment data, always join through gc:resultForPeopleGroup -- never expect assessment metrics directly on the PeopleGroup.
owl:sameAs links GC people group URIs to their source system URIs for cross-reference.

See also: the People Group Model reference page covers the four-layer shape (concept / collective / population segment / community), the 17 scope types, multi-source classification, population estimates, and reachedness assessment results.

Modeling Activity Reports

Ministry activities produce reports that capture outcomes. The ontology uses a 3-layer pattern: Plan (optional) → Activity → Report. This example shows a baptism activity and its report — the same pattern applies to gospel conversations and other ministry types.

Turtle

Code
 
@prefix gc: <https://ontology.global.church/core#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# The activity
<https://data.global.church/activity/baptism-2026-03-01>
  a gc:BaptismActivity ;
  gc:engagesPeopleGroup <https://data.global.church/jp/pg/110532-IN> ;
  prov:wasAssociatedWith <https://data.global.church/org/example-church> ;
  prov:startedAtTime "2026-03-01"^^xsd:date ;
  gc:hasLanguageClassification <https://data.global.church/his/rol/urd> .

# The report (outcomes)
<https://data.global.church/activity/baptism-2026-03-01/report>
  a gc:BaptismReport ;
  prov:wasGeneratedBy <https://data.global.church/activity/baptism-2026-03-01> ;
  gc:numberOfBaptized 12 .

Key Points

Activity vs. report separation. The activity captures what happened (who, where, when, which people group). The report captures what was produced (number of baptisms, number of decisions, etc.). This follows the PROV-O Activity → Entity generation pattern.
gc:BaptismReport is a subclass of gc:ActivityReport. The gc:numberOfBaptized property is specific to baptism reports (distinct from gc:numberOfBaptizedBelievers, which is a community demographic on gc:EkklesiaCommunity).
gc:GospelConversation + gc:GospelConversationReport follow the same pattern for gospel sharing outcomes.
Inherited gc:MinistryActivity properties (people group, language, religion, location, contributors) apply to all activity subtypes — no need to redeclare them.

URI Patterns

The knowledge graph uses consistent URI patterns for all entities:

Entity Type	URI Pattern	Example
Organization	`https://data.global.church/org/{slug}`	`.../org/wycliffe`
JP People Group	`https://data.global.church/jp/pg/{ROP3}-{ROG3}`	`.../jp/pg/110532-IN`
JP Assessment	`https://data.global.church/jp/assessment/{ROP3}-{ROG3}`	`.../jp/assessment/110532-IN`
JP Result	`https://data.global.church/jp/result/{ROP3}-{ROG3}`	`.../jp/result/110532-IN`
ROP3 People	`https://data.global.church/his/rop3/{code}`	`.../his/rop3/110532`
ROL Language	`https://data.global.church/his/rol/{iso639-3}`	`.../his/rol/urd`
ROR Religion	`https://data.global.church/his/ror/{code}`	`.../his/ror/M`
ROG Geography	`https://data.global.church/his/rog/{code}`	`.../his/rog/IN`

Next Steps

SPARQL Quickstart -- query the data you now understand
Contributing Linked Data -- submit your own data to the graph
Data Quality and SHACL -- understand validation rules

Last modified on May 25, 2026

UUPG+ Lists Needs & Commitments