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.
How We Model 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.
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").
How We Model a Church
A gc:Church is a subclass of gc:Organization. Every church is also an organization, inheriting all organization properties. Church adds properties specific to local congregations: multi-campus status, community state, gathering state, and services information.
In the data, churches carry botha gc:Organization, gc:Church (explicit OWL class) andgc:hasOrganizationType gc:OrgTypeChurch (SKOS classification). The OWL class enables SHACL validation targeting; the SKOS concept enables multi-typing (a church can also be gc:OrgTypeMissionAgency).
gc:servesPeopleGroup links a church to the people groups it intentionally serves (distinct from gc:targetsPeopleGroup which is automated geographic association).
Other organization types (Mission Agency, Denomination, Network, etc.) remain SKOS-only — they don't have enough type-specific properties to warrant OWL subclasses.
How We Model an Engagement
An engagement connects an organization to a people group through an activity. This uses the PROV-O participation pattern:
The engagement is modeled as an activity, not a property on the organization. This lets you attach provenance (who recorded it, when, based on what evidence).
prov:qualifiedAssociation is the PROV-O pattern for attaching a role to a participation. The same person or organization can play different roles in different activities.
Activity roles (FieldWorker, Leader, Trainer, ChurchPlanter, etc.) describe a function performed -- they are data, not permissions.
How We Model a People Group
A gc:PeopleGroup represents a people-group-in-country (PGIC). Identity properties live directly on the people group. Assessment data uses the 3-block pattern: PeopleGroup + gc:Assessment + gc:AssessmentResult.
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.
How We Model 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:ChurchCommunity).
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:
