This paper introduces the Compass ontology and proposes a design pattern aimed at supporting the formal representation of information about clients, services, and events in a social service setting. The framework captures entities required to represent the interaction between clients and services and events that track progress through changes exhibited by these stakeholders. The Compass ontology is an extension of the Common Impact Data Standard. It introduces classes and properties that allow it to answer a set of competency questions posed by subject matter experts in the area of social service provisioning. We evaluate the ontology using sample competency questions implemented in SPARQL.
As cities grow in size and complexity, it becomes increasingly difficult to identify whether
the right city services are being provided to the right citizens and at the right time. This
paper introduces the Compass ontology and its design pattern aimed at supporting a formal
representation of information about clients, services, and events in a social service setting. Our
methodology behind design decisions is application agnostic while allowing the representation
of a variety of service providers and their clients, and accommodating different levels of
information, from simple text descriptions and enumerated vocabularies to a rich representation
of concepts and their relationships. Conceptual analysis is provided in Fox et al. [
Organizations delivering social services are referred to as social purpose organizations (SPO)
and are made up of charities, non-profits, and other social-purpose businesses [
Recently, there have been efforts to define how to measure the impact of SPOs [
An ontological representation of service impact has long been a topic of interest for service
providers, clients, and contributors like funding organizations. Over the years, various impact
models have been developed for this purpose, including Logic Models, Theory of Change,
Outcome Map, Outcome Chains, and Impact Map, each one having a different representation of
how to model SPO impact [
The Compass ontology, presented here, extends the Common Impact Data Standard (CIDS)
[
An Event describes something that occurs to a stakeholder as an ‘‘event’’ in their life, identifying the location and time at which it occurred. It can describe the client as being the subject of an action or a change of state. The Compass Event class extends the 5078-1:Activity class 1Impact Management Project: https://impactmanagementproject.com 2The Compass ontology was developed with, and is being used by HelpSeeker: https://helpseeker.co. 3Subject matter expert requirements and use-cases were collected by HelpSeeker: https://helpseeker.org. 4Code available at https://github.com/csse-uoft/jowo-2022.
State (enabling)
Event (previous) enabledBy
Activity Event subClassOf causes nextEvent
State
(caused)
Event
(next)
defined in the 5078-1 ISO Standard [
⊑ 5087-1: ⊓ =1 ℎ .: ⊓ =1 .: ⊓ =1 .
⊓ ∀ ℎ.:
⊓ =1 ℎ.72:
⊓ =1 .
(DL-1)
The Client class represents a person who uses services and, potentially, benefits from their
outcomes. The class inherits all properties of 5087-2:Person and satisfies the needs related to
cids:Stakeholder class, categorized by the stakeholder’s characteristics, as shown in Figure 2.
A stakeholder, where Stakeholder ⊑ (Organization or Person), can be related to a number of
concepts, such as outcomes and locations, which characteristics cannot. At the same time, a
client can be characterized along multiple dimensions, such as age and gender and a specific set
of needs, such as addiction and homelessness. A specific service can be interested in a subset
of those characteristics, such as a minimum age requirement for a homeless shelter. Hence, a
client can be matched with services at the stakeholder rather than characteristic level. This
allows for more flexibility in associating clients and services with stakeholders, and in turn,
outcomes and location. Please refer to the CIDS manual for further details [
Beneficiary Stakeholder performs
I72: located_in i72:Feature hasCharacteristic
Characteristic oep: partOf ImpactModel knowsLanguage hasServiceEvent hasEducationEvent hasEmploymentEvent hasImmigrationEvent hasMedicalEvent hasJusticeSystemEvent Language
Ability
Service Event
Education
Event
Employment
Event
Immigration
Event
Medical . . . JusticeSystem Event Event
• satisfiesStakeholder: Identifies the stakeholder specifications that the client satisfies. • hasGender: A coded property specifying the gender. • hasEthnicity: A coded property specifying known ethnicities of the client. • memberOfAboriginalGroup: A coded property identifying client’s aboriginal group. • hasReligion: A coded property specifying known religions of the client. • hasDependent: A set of Person instances, such as children or parents.
• schema:knowsLanguage: LanguageAbility instances, known and proficiency.
Some properties of the Client classes are ‘‘coded properties’’ where the range of values is constrained by client taxonomy codes, instances of ClientCode, where ClientCode ⊑ cids:Code. Such codes are subclasses of the ClientCode class. For example, the class CL-Age can have instances of age categories, including INST-Young and INST-Adult. The subcategories for basic demographics include Age, Ethnicity, Family status, Gender, Religion, and Sexuality.
Central to the representation of information about a client are events that have occurred in their life. These events can span medical (in and out of institutions like hospitals), educational, housing, etc. Client events are used to derive characteristics of a client at some point in time. For example, one or more housing events may be used to determine that a client is homeless. Events can be viewed as records of a client’s life and viewed retrospectively to understand their pathways. The Client class extends the definition in DL-2 with the following additional event-related properties, as shown in Figure 3: • hasServiceEvent: instances of ServiceEvent for a service the client has received. • hasEducationEvent: instances of EducationEvent for education the person has received. • hasEmploymentEvent: instances of EmploymentEvent. • hasImmigrationEvent: instances of ImmigrationEvent, each defining stages of immigration, if relevant. • hasMedicalEvent: instances of MedicalEvent defining separate medical events, including births and deaths. • hasHousingEvent: instances of HousingEvent that track changes in housing statusincluding homelessness. • hasNameEvent: instances of NameEvent. • hasGenderEvent: instances of GenderEvent. • hasBirthEvent: instances of BirthEvent. • hasDeathEvent: instances of DeathEvent. • hasMaritalEvent: instances of MaritalEvent. • hasHomelessEvent: instances of HomelessEvent.
• hasJusticeSystemEvent: instances of JusticeSystemEvent.
DL 3 (Compass Client Class). ⊑ 5087-2: ⊓ ∀ ℎ. ⊓ ∀ ℎ . ⊓ ∀ ℎ . ⊓ ∀ ℎ. ⊓ ∀ ℎ . ⊓ ∀ ℎ. ⊓ ∀ ℎℎ.ℎ ⊓ ∀ ℎℎ.ℎ ⊓ ∀ ℎ. ⊓ ∀ ℎ. ⊓ ∀ ℎ. ⊓ ∀ ℎ . (DL-3) The definition for the EducationEvent class is provided below, with remaining client-related event definitions omitted. An EducationEvent is used to describe a client’s educational or training status and experience. It is a subclass of ClientEvent and introduces the following properties: • hasStatus: the status of the education event, complete, inProgress or incomplete. • atOrganization: identifies the education organization the event took place. • hasCertification: identifies the type of certification the education event has. • hasType: identifies the type of education, including BA, BSC, etc.
⊑ ⊓ =1 . ⊓ ∀ ℎ .- ⊓ ∃ ℎ . ⊓ ℎ.({} ⊔ { } ⊔ {})
StakeholderEvent: The StakeholderEvent captures events performed by stakeholders. The cids:Stakeholder class is a subclass of an Organization or 5087-2:Person and identifies a person or organization required to answer competency questions such as: ‘‘How many users interacted with service?’’, ‘‘How long did #6 stay in counselling?’’ and ‘‘How are people looking for help?’’. The StakeholderEvent extends the Event class with the following property.
• forStakeholder: the stakeholder related to this Event instance.
ℎ ⊑ ⊓ =1 ℎ.:ℎ
The service is comprised of activities that focus on a shared set of inputs, outputs, and outcomes. It also defines a set of stakeholders that contribute to or benefit from the service. The Compass Service class defines a service provider and inherits all properties from the cids:Service class, which in turn is a subclass of 5087:Activity. As such, a Service can be thought of as performing activities that cause some events to occur. (DL-4) (DL-5) subClassOf CSCSototananktketrerihbihbououltdltidneinegrgr contributes
A program is comprised of one or more services. For example, a ‘‘poverty reduction’’ program can have many services, with each service consisting of different activities, such as ‘‘find housing’’, ‘‘assess housing readiness’’, and ‘‘rent subsidy’’, and complementary inputs, outputs and outcomes. The Compass Program class extends the cids:Program class by redefining hasService to include the Compass Service class and adds an ic:hasAddress property. This extension allows an organization to provide services at different locations. For example, a ‘‘health’’ service can set up multiple offices closer to its clients.
• hasService: Identifies the Services that comprise this Program.
• ic:hasAddress: Identifies the address for this Program.
⊑ : ⊓ ∀ :ℎ ⊓ =1 ℎ.: (DL-6)
The Compass Service class is an extension of the cids:Service class. As described in [
• hasRequirement: Identifies characteristics that limit who can use the service, listed in service taxonomy code list. • hasFocus: Identifies client characteristics that the service focuses on, listed in service taxonomy code list. • hasMode: The mode with which the service is delivered.
• providesSatisfier: The need satisfier this service provides.
⊑ : ⊓ ∀ ℎ.:ℎ ⊓ ℎ .({} ⊔ {ℎ} ⊔ {} ⊔ { }) ⊓ ∀ ℎ .:ℎ ⊓ ∀ . Similar to the Client class, some properties of the Service classes are ‘‘coded properties’’, meaning their range of values is constrained by service taxonomy codes, instances of ServiceCode where ServiceCode ⊑ cids:Code.
ServiceEvent: A ServiceEvent is an event performed by a service that changes a client’s state in some way. It has the following properties: • hasStatus: Status of the service. • atOrganization: The organization providing the service.
• forReferral: The referral that led to the service event, if any.
⊑ ⊓ ℎ.({ℎ} ⊔ { } ⊔ {}) ⊓ =1 . ⊓ ∀ . (DL-7) (DL-8) ApplicationEvent: When clients interact with service providers through a computer application, interaction-logging capabilities capture information related to service access. Relevant use cases include competency questions such as: ‘‘Who are the highest systems users currently?’’ and ‘‘What are the system interactions patterns for these clients over past 3 months?’’. An ApplicationEvent is a subclass of Event. It defines an event created by an Application instance and captures any information relevant to that event.
• hasApplication: the application this event was created in • hasUserStakeholder: the stakeholder using the application when the event was created. • dateCreated: timestamp when the event was created • hasSource: the URL or unique address where this event originated • hasMetaData: the information stored with the event DL 9 (Compass ApplicationEvent Class).
⊑ ⊓ =1 ℎ.ℎ ⊓ =1 ℎ ℎ.ℎ ⊓ =1 ℎ.: ⊓ =1 ℎ. ⊓ =1 ℎ:.: ⊓ ∀ ℎ .: (DL-9) ServiceFailureEvent: The Compass ServiceFailureEvent class represents an event triggered when there is a barrier preventing clients from using a service they are otherwise eligible for. It also provides a solution, if one exists. This event occurs when there is a discrepancy between the service’s requirements and the client’s characteristics. For example, if a client is experiencing substance abuse (INST-Addiction), and a shelter (cp:shelter-A) requires its participants to be sober (INST-Sober), a ServiceFailureEvent is triggered. The triggered event’s properties will be: forService = cp:shelter-A, hasCharacteristic = INST-Sober, and hasFailureType equals any service or activity that, as its outcome, removes INST-Sober or adds INST-Addiction as the client’s characteristics. The ServiceFailureEvent class has the following properties: • forService: Service or Activity this failure event indicates cannot be used by a client. • hasCharacteristic: Characteristic causing the failure, i.e. service requirements not matching a client’s characteristics. • hasFailureType: Service or Activity preventing the stakeholder from using the service. • hasDescription: description of the failure type.
⊑ ⊓ ∀ .( ) ⊓ =1 ℎℎ.ℎ ⊓ =1 ℎ .( ) ⊓ ∀ ℎ.: (DL-10) Clients can interact with service providers through a online software system, represented by the Application class, a subclass of Service, extending it with the following property: • hasSource: The URL or unique address where the application can be referenced.
⊑ ⊓ ∀ ℎ.:
4.1. Client Community Pattern
(DL-11)
A community is made up of two or more individuals that share some characteristics, such
as age, gender, or set of goals, like finding housing or sobriety. These characteristics are
represented as characteristics of the community. We also associate the characteristics of the
clients with the location they reside in, to understand the service’s catchment area.
50782:CityAdministrativeArea class is imported from the 5078-2 ISO standard [
⊑ 5087-2: ⊓ ∀ ℎℎ.ℎ (DL-12) CommunityCharacteristic: The CommunityCharacteristic references the identifying characteristics that several individuals have in common that in turn makes them a community. • hasCommunityCharacteristic: the characteristic that defines this Community • hasNumber: the number of people in the community (not all individuals in a spatial area, only those that fit the CommunityCharacteristic profile.
ℎ ⊑ : ℎ ⊓ ∀ ℎℎ.:ℎ ⊓ =1 ℎ .: (DL-13)
In previous work [
5Date arithmetic functions for ofn: and spif: defined at https://graphdb.ontotext.com/documentation/9.10/free/ sparql-functions-reference.html. [EducationEvent] What is our clients’ education history and status? This question queries cp:EducationEvent instances. It identifies two clients. cp:Client400 who is currently attending a ‘‘trade school’’, as indicated by status=cp:inProgress, after having completed ‘‘gradeschool’’ and ‘‘high school.’’ cp:Client401 has also graduated ‘‘gradeschool’’ and ‘‘high school’’, and is scheduled to start attending ‘‘higher education’’. The results are listed in Table 2. 1 SELECT DISTINCT ? c l i e n t ? eduEvent ? s t a r t F ? endF ? s t a t u s 2 WHERE { 3 ? eduEvent r d f : t y p e cp : E d u c a t i o n E v e n t ; 4 cp : f o r C l i e n t ? c l i e n t ; 5 cp : h a s S t a t u s ? s t a t u s ; 6 time : h a s B e g i n n i n g ? s t a r t . 7 BIND ( s p i f : d a t e F o r m a t ( ? s t a r t , " d−M−Y " ) as ? s t a r t F ) . 8 OPTIONAL { ? eduEvent time : hasEnd ? end } . 9 BIND ( s p i f : d a t e F o r m a t ( ? end , " d−M−Y " ) as ? endF ) . 10 } ORDER BY ? c l i e n t ? s t a r t [ApplicationEvent] What stakeholders access our application most frequently? This question queries cp:ApplicationEvent instances, identifying two types of Application accessed (app) and three types of stakeholders (sh), as listed in Table 3. appEvents sums the number of instances by app and sh. The top event cp:App_CounselingSessions is used by the cp:FemaleHousedYouthin_Area0 stakeholders, totalling 12 instances. This stakeholder’s characteristics are linked to Code values identifying female youths that live in the location ‘‘Area0.’’ 1 SELECT DISTINCT ? app ? sh ( count ( ? appEvent ) as ? appEvents ) 2 WHERE { 3 ? appEvent r d f : t y p e cp : A p p l i c a t i o n E v e n t ; 4 cp : h a s A p p l i c a t i o n ? app ; 5 cp : h a s U s e r S t a k e h o l d e r ? sh ; 6 cp : o c c u r s A t ? o c c u r s . 7 BIND ( s p i f : d a t e F o r m a t ( ? occurs , " d−M−Y hh :mm" ) as ? o c c u r s F ) .
8 } GROUP BY ? app ? sh ORDER BY ? app DESC ( ? appEvents )
This paper introduces the Compass ontology and evaluates its ability to answer a set of competency questions posed by various stakeholders in social services. The answers to the selected queries were extracted from a knowledge graph based on the Compass ontology and populated with client, service, service usage, and events data.
Our evaluation demonstrates how competency questions can be answered using the Compass ontology. Service queries identify service events aggregated to answer temporal questions related to the length of client usage of a service category, namely counselling services. By associating services with a specific code, like INST-Counseling, the query can aggregate over all service instances a client used. We can also track a client’s progress and infer their latest state by identifying the last ‘‘complete’’ client event, such as EducationEvent to infer their education status. Finally, we can evaluate software system usage by analyzing application logs associated with the characteristics of system users. We can then answer questions about the most frequent usage by client categories defined by the ClientCode instances, such as age, gender, housing status, and location. The event, client, service definitions and code taxonomies continue to be extended to ensure ontological concepts defined by Compass are shared and compared between organizations working towards similar or overlapping outcomes.