An Ontological Approach to Analysing Social Service Provisioning

06/20/2022
by   Mark S. Fox, et al.
0

This paper introduces ontological concepts required to evaluate and manage the coverage of social services in a Smart City context. Here, we focus on the perspective of key stakeholders, namely social purpose organizations and the clients they serve. The Compass ontology presented here extends the Common Impact Data Standard by introducing new concepts related to key dimensions: the who (Stakeholder), the what (Need, Need Satisfier, Outcome), the how (Service, Event), and the contributions (tracking resources). The paper first introduces key stakeholders, services, outcomes, events, needs and need satisfiers, along with their definitions. Second, a subset of competency questions are presented to illustrate the types of questions key stakeholders have posed. Third, the extension's ability to answer questions is evaluated by presenting SPARQL queries executed on a Compass-based knowledge graph and analysing their results.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

04/04/2022

Extracting Impact Model Narratives from Social Services' Text

Named entity recognition (NER) is an important task in narration extract...
03/14/2018

What Should You Know Before Developing a Service Identification Approach

In this paper, we answer a set of research questions that are required t...
05/28/2021

Social Engineering in Cybersecurity: A Domain Ontology and Knowledge Graph Application Examples

Social engineering has posed a serious threat to cyberspace security. To...
10/01/2016

Consistency Ensuring in Social Web Services Based on Commitments Structure

Web Service is one of the most significant current discussions in inform...
12/13/2020

Knowledge Graph Management on the Edge

Edge computing emerges as an innovative platform for services requiring ...
04/27/2022

Discrete Event Simulation to Evaluate Shelter Capacity Expansion Options for LGBTQ+ Homeless Youth

The New York City (NYC) youth shelter system is instrumental in providin...
05/14/2020

Information Design for Congested Social Services: Optimal Need-Based Persuasion

We study the effectiveness of information design in reducing congestion ...

1 Introduction

Within any region, there exists a myriad of social services designed to meet citizens’ needs. The provisioning of these services is provided by government agencies at the national, provincial/state and local levels. They are also provided by Non-Government Organizations such as non-profits, charities and social enterprises. The number of agencies involved is surprisingly large. For example, Canada has over 170,000 charities and non-profits, and the United States has over 1.54 million. The providers of social services distinguish themselves along many dimensions, two of which are the type of service they provide and the target group (beneficiary stakeholder) the service is designed to help

Services range across many areas, such as housing, food, and training. Stakeholders are differentiated across dimensions such as age, gender and medical conditions. The variety of services differentiated by target stakeholders leads to endless variations of what is determining whether the plurality of social services are meeting their citizens’ needs.

As our society evolves into a richer mosaic of cultures, ethnicities, etc., cities are challenged in determining whether needs are being met, by various stakeholder distinctions. The broad categories used for social service provisioning are no longer sufficient (DAquin2015; Daga2016; Lytras2018). A deeper representation of stakeholder characteristics, their needs and how social services satisfy them is required. This paper defines such a representation: the Compass ontology.

In section 2, we present a set of coverage questions posed by social services stakeholders. In sections 3, 4, 5, and 6, we identify key ontological components required to answer the proposed coverage questions and describe the Compass ontology111The Compass extension is prefixed with the cp: namespace. When no namespace is provided, cp: is implied., an extension to the Common Impact Data Standard (CIDS)222The CIDS ontology is prefixed with the cids: namespace. (Fox2021). Finally, in section 7 we evaluate the extension by showing sample SPARQL queries and results generated from a knowledge graph built using the Compass extension333Code available at https://github.com/csse-uoft/ieee-isc2-2022.. In section 8 we conclude by discussing the evaluation results and discuss the state of the ontology and future work.

Figure 1: Common Impact Data Standard Core Classes.

2 Usage Scenarios and Competency Questions

2.1 Modeling Service Coverage

Coverage of service refers to the variety of services available in a particular location and how accessible those services are to the communities that need them. Hence, to determine service coverage, we must identify several key ontological components. The Compass ontology extends the Common Impact Data Standard depicted in Figure 1. CIDS defines one or more Impact Models for an Organization. Each Impact Model can have one or more Programs, each having set of general Stakeholders, Outcomes and Indicators. Each Program has one or more Services with more specific Stakeholders, Outcomes and Indicators. Services are composed of Activities that have Inputs, Outputs and associated Indicators.

The cids:Outcome class defines the resulting state of service provisioning, generally in a larger scope that captures the long-term impact of a service on a community. The cids:ContributingStakeholder class represent stakeholders that perform some activities towards achieving the outcome by providing resources (e.g. funding) or administering services (e.g. front-line workers). The cids:BeneficialStakeholder class represents stakeholders impacted by the outcome, whether in a positive, negative, or neutral way. These include clients that benefit directly from a service as well as organizations that receive resources or share activities with other contributing stakeholders.

Services, clients and needs may be categorized along a variety dimensions that external organizations define themselves or are defined differently in related sectors. Hence, the Compass ontology includes a set of taxonomies that define unique codes for each dimension that reference external representations.

Figure 2: Common Impact Data Standard Stakeholder class and its core classes.

2.2 Client Stakeholders Usage Scenario and CQs

Clients can be identified by their level of need. Low need clients are those that are generally able to care for themselves, but require some assistance. High need clients have similar needs, but require additional assistance, such as advocacy on behalf of a renter to negotiate rent or assistance for people with a history of trauma in performing daily tasks, such as shopping or filling out forms with sensitive information. Super High Need Clients require assistance with the majority if not all of their daily tasks and access to services. Assistance may include gathering information about available food programs, access to governmental benefits and pension, and help resolving barriers to service. The questions clients ask include:

Client CQ-1

(1.1) What services am I eligible for and (1.2) what barriers exist for me to access them?

Client CQ-2

What shelter services are available in my community?

Client CQ-3

Which services match my needs?

Client CQ-4

I have a history of trauma; am I going to have to talk about that in the program?

Client CQ-5

(5.1) What are the rules at the shelters? (5.2) Do I have to be sober? (5.3) Where is the building?

Client CQ-6

If I don’t like the program what are my other options?

Client CQ-7

(7.1) What are you going to do with my data in the program? (7.2) Can the police or government access the system?

2.3 Service Stakeholders Usage Scenario and CQs

Service stakeholders are those that work for social purpose organizations to deliver services to clients. These include partner organizations that support each other as contributing stakeholders towards a common outcome.

We will focus on three key service stakeholders selected by subject matter experts. A complex needs coordinator is a person who manages clients with complex needs. They are responsible for managing client needs and ensuring services are available when needed. A service manager is responsible for managing individuals and resources who deliver services, such as food inventory as well as peer counsellors, shelter facility maintenance staff, and volunteers. Finally, front-line service worker is a role that involves interacting directly with clients on a daily basis. They are responsible for being familiar with the needs of the client, their current status in a program, and the people most likely to help or hinder the client’s well being. The questions service providers may ask include:

Service CQ-1

What are the key demographics of the highest systems users (age, ethnicity, immigration, etc)?

Service CQ-2

How long did client #2 stay in counselling?

Service CQ-3

What is causing barriers to accessing Housing?

Service CQ-4

What other programs or services could I refer clients to at this time?

2.4 Outcome-Related Stakeholders Usage Scenario and CQs

Outcome related stakeholders are those that focus on “big-picture“ questions asking how communities are impacted by specific outcomes, and how resources (i.e. need satisfiers) are distributed. In some instances, the outcomes may be related to a specific need, a specific demographic group, or a combination of the two, such as “addiction services for people experiencing homelessness” or “the long-term housing needs of marginalised communities (LGBTQ, new immigrants, etc)”. Depending on their role, such stakeholders may or may not be part of the organizations that directly deliver services to clients. For example, an executive director is responsible for the growth of a service providing organization and ensuring that key performance indicators are met. They focus on meeting the targets set out by the organization and reaching out to community and service partners. On the other hand, senior managers at funding agencies are contributing stakeholders interested in how their funding is used to achieve their target outcome. The questions such stakeholders may ask include:

Outcome CQ-1

What are the associated priority demographic groups?

Outcome CQ-2

What is the representation of these groups in my community?

Outcome CQ-3

What housing services are available by gender, racialized identity, age etc.?

Outcome CQ-4

What areas is funding currently going toward and how much of this funding is my organization getting?

Outcome CQ-5

What are our gaps and duplicates for services or funding?

3 Client Pattern

The Compass Client class connects to the main Service and ClientNeed class extensions through the cids:Characteristic, cids:Stakeholder, and cids:Code classes. The Client inherits all properties of 5087-2:Person (5087-2) and satisfies needs of a cids:Stakeholder. Figure 2 depicts main cids:Stakeholder classes and properties, with further details in Fox et al.(Fox2021).

Some properties of the Client classes are “coded properties”, meaning their range values are constrained by client taxonomy codes444Each code is a subclass of cids:Code, and related to other classes through the cids:hasCode property. For example, client taxonomy codes are subclasses of the ClientCode class, which is itself a subclass of cids:Code. Each client code is an instance of a specific ClientCode subclass. For example, the class CL-Age can have several age categories, including cp:INST-Toddler, cp:INST-Young and cp:INST-Adult. Similarly, ServiceCode and NeedCode define codes for services and needs.. Different subcategories for basic demographics include Age, Ethnicity, Family status, Gender, Religion, and Sexuality. The taxonomy also lists different categories for a client’s status along dimensions of Citizenship, Finance, Education, Employment, and a Legal context. It also provides codes for categories of a client’s living situation, including shelter type, level of homelessness, and safety ranking. A client’s constraints cover physical and mental health status as well as any non-health related constraints such as cultural barriers and social limitations. Finally, any property, coded or not, can be qualified with a Rank defined in the client taxonomy, such as acute, complex, severe or stable, as well as a Temporality, such as past, long-term, and ongoing. Client properties related to needs and outcomes are defined in section 5.

The Compass Client extends the 5078-2:Person class with additional properties, as shown in Figure 3. satisfiesStakeholder is the stakeholder this client represents. The cids:Stakeholder class provides the hasOutcome property that identifies instances of StakeholderOutcome, specifying outcomes experienced by the client. hasGender is a coded property specifying the client’s gender. hasEthnicity is a coded property specifying known ethnicities of the client. memberOfAboriginalGroup is a coded property identifying the aboriginal group the client is a member of, if any. hasReligion is a coded property specifying known religions of the client. hasDependent is a set of 5087-2:Person instances that identify the client’s dependents, such as children or parents. schema:knowsLanguage links to instances of LanguageAbility that specifies languages known and their proficiency.

Figure 3: Client class extension and related Event classes.

4 Service Pattern

Figure 4: Compass extension of the Service class and its core classes.

The cids:Service class defines a set of activities, inputs, outputs, and outcomes that can be administered through a logic model and program. A service also defines a set of stakeholders that may contribute to or benefit from the service. The Compass Service class extends cids:Service and inherits all its properties. The core classes are shown in Figure 4. The Compass Service extension connects the main Client and ClientNeed classes through the cids:Characteristic, cids:Stakeholder, and ServiceCode classes. Since a service may be administered by providers at different locations, the Compass Program class extension introduces the ic:hasAddress property that identifies the unique address for a program.

The Service class extension has the following properties. hasRequirement identifies characteristics that limit who can use the service, listed in the client taxonomy code list. providesService identifies codes for categories of services provided, as listed in service taxonomy code list, where each code is a subclass of ServiceCode. For example, different types of education services are instances of the class CL-Education, and include INST-Gradeschool, INST-Highschool as well as 1_on_1_Coaching and INST-Educational_Workshops. A summary of services covered by the service code taxonomy is provided at the end of this section.

Next, the hasFocus property identifies client characteristics that the service focuses on, listed in the client taxonomy code list. hasMode specifies the mode with which the service is delivered, and can be one of {in-person, phone, online, offline}. Finally, providesSatisfier identifies the need satisfier this service provides, described section 5.

To define capacity of a service provisioning, we first need to define the community component of a service provider, meaning, the communities services target, if any. 5078-2:CityDivision class is extended from the ISO 5078-2 standard (5087-2) to capture this functionality. A Community class identifies two or more individuals that share some characteristics. The hasCommunityCharacteristic property identifies characteristics of the community this class represents. The CommunityCharacteristic class references the identifying characteristics that several individuals have in common that in turn make them a community. hasCommunityCharacteristic identifies the characteristic that defines this Community. hasNumber is the number of people in the community limited to those that match these characteristic.

Clients can interact with service providers through a computer application, defined as Application. The Application class extends Service class with an additional property, hasSource, that identifies the unique resource locator (URL) or unique address where the application can be referenced.

The service code taxonomy includes categories of services as instances of the ServiceCode class. For example, Cl-Health includes short- and long-term medical services, including hospital stays and pharmaceutical services. CL-Cost specifies the cost category of the service, including “paid,” “sliding scale” or “through a subsidy.” CL-Personal services are those that clients require to live their daily lives, such as transportation and laundry services. Shelter services provide housing programs for clients, including short- and long-term housing and specialized housing. Additional codes are defined for CL-Advocacy, CL-Referral, CL-Education, CL-Employment, CL-Relationships, CL-Finance, CL-Goods, and CL-Food.

5 Needs Pattern

Figure 5: Client related classes for needs and outcomes.

Needs provide the conceptual focus for service provision, and social work practice in general (gough2020; desmet2020; henwood2015). Our representation of client needs, embodied in the Compass class ClientNeed, defines the changes needed in a client’s state. It relies on two elements: 1) a type of measurable personal feature that would be changed or maintained, such as employment or mental health state (pay rent, enroll kids in school), and 2) an action (e.g., improve, acquire, develop). Based on the type of change sought, client needs can be divided into several categories, such as acquiring-needs and improving-needs. The operationalization of client needs as differences between the actual and desired (or prior- and post-service provision) values of measurable features allows us to infer a client’s current needs as well as check the satisfaction of those needs via observable client outcomes. The Compass ClientNeed class is connected to the Compass ClientGoal class, and through that, to the Compass ClientProblem class.

The ClientProblem class is a cognitive representation of the discrepancy between an a client’s actual and desired states. The use of the term problem has a long pedigree in Social Work. Problems are used to identify the key areas related to clients’ circumstances that are relevant for social work practice and are often recorded in client files as proxies for needs. The ClientGoal class is a cognitive representation of reducing the gap between the desired and the actual state, if the two are different, or maintaining or ensuring a 0-distance between the desired and the actual state, if the two are the same. For example, a person who is “couch surfing” may wish to have a permanent place to live. Here, experiencing homelessness rather than being “housed” is a problem that motivates the goal of being stably housed. Given their current state and their stated goal, this person’s need is to improve their housing.

As shown in Figure 5, the Client class has properties that allow for clients to be connected with their states, problems, goals and needs. hasClientState links to instances of ClientState that specify the state the client is in. hasProblem links to instances of ClientProblem that specify the problems of the client. hasGoal links to instances of ClientGoal that specify the goals of the client. hasNeed links to needs while hasAcquityScore specifies their acuity level, as assessed by a healthcare professional, and recorded as a string value such as {“Low”, “Medium”, “High”} or {“1”, “2”, “3”}. hasStatus links to instances of Status that specify the status of the client.

Client needs are met via need satisfiers (zins2001; human2018), represented in Compass by the NeedSatisfier class. The “couch surfer” in our example could have their need met by satisfiers such as rent supplements and supportive short-term accommodations. The connection between ClientNeed and NeedSatisfier is captured by the property hasNeedSatisfier. A satisfier’s type, such as pseudo satisfier and inhibitor, is specified via property hasType. Property forNeed connnects a need satisfier with needs it can fully or partially fulfill. The client states impacted by its provision are identified using property changes.

6 Event Pattern

An Event describes something that occurs at some location, at some time, and involves a Stakeholder. It can describe the stakeholder as being the subject of an action, or a change of state. The basic Event class has the following properties: occursAt is the time interval during which the event occurs; hasLocation is the placename where the event occurred; and previousEvent links this event to a previous, related event while nextEvent links it to the next related event, if any. Next, we provide extensions to basic Event class.

6.1 Client Event Pattern

The ClientEvent class, a subclass of Event, is used to log significant events that are relevant to a client. They capture personal events, such as marriage, illness, employment, homelessness, and so on. ClientEvent is a subclass of Event and inherits all of its properties. It also adds the forClient property. For example, one or more housing events may be used to determine that a client is homeless. A “has” property is defined for each event, for example, the property hasHousingEvent identifies a HousingEvent instance for the client, and allows us to track a client’s transition from “housed” to “institutionalized”, “homeless” and “housed” again. Events can be viewed as records of a client’s life, hence can be used retrospectively to understand a client’s pathways. A subset of client events are listed next. Additional client events related to a client property or status include EducationEvent, EmploymentEvent, MedicalEvent, MilitaryEvent, ImmigrationEvent, HousingEvent, NameEvent, GenderEvent, BirthEvent, DeathEvent, MaritalEvent, HomelessEvent, and JusticeSystemEvent.

The StakeholderEvent captures events relevant to any stakeholder, not just a client. It extends the Event class with the forStakeholder property that identifies the cids:Stakeholder associated with this Event instance.

ServiceFailureEvent represents an event triggered when a barrier exists that prevents clients from using a service they may be otherwise eligible for. It extends the ClientEvent class with the following properties. forService identifies the Service or Activity this failure event indicates cannot be used by a client. hasCharacteristic identifies the characteristic that caused the failure, such as an eligibility requirement that was not met (e.g. a person without identification cannot access their medication as it requires a health card). hasFailureType identifies the cp:Service or cids:Activity type as a precondition for the service that might remove the barrier. For example, an ID clinic could provide the client with the required health card.

6.2 Service Event Pattern

The Compass Service coverage competency questions also require the definition of events. A ServiceEvent is an event that changes a client in some way. It extends the Event class with the following properties. hasStatus is the status of the service, and can take the value of {scheduled, inProgress, or completed}. atOrganization identifies the organization providing the service. Finally, hasReferral identifies the referral that led to the service event, if any.

For clients interacting with an instance of the Application class, their activities are logged as ApplicationEvent instances. It captures any information relevant to that event, including functional data and metadata. The hasApplication property identifies the application this event was created in. hasUserStakeholder identifies the stakeholder that was using the application when the event was created. hasSource identifies the URL or unique address where this event originated, and may differ from the address listed for the Application instance. hasMetaData identifies the information stored with the event.

7 Evaluation

The Compass extension to the Common Impact Data Standard, identified by the namespace prefix cp:, was evaluated using a subset of competency questions listed in sections 2.2, 2.3, and 2.4, and translated into SPARQL. The queries are run on a Compass-based knowledge graph and populated with synthetic data modeled after real data555Real data provided by Help Seeker Technologies: helpseeker.org..

[Client Q-3] Which services match my needs? The SPARQL query provided below retrieves services for a client with the internal identifier cp:Client16 who is experiencing homelessness and struggles with addictions. Their needs are to reduce their suffering from addiction and improve their housing situation.

1SELECT DISTINCT ?service ?code WHERE {
2    BIND(cp:Client16 AS ?client).
3    ?client  cp:hasNeed  ?need.
4    ?need  rdf:type  cp:ClientNeed.
5    ?needSatisfier  rdf:type  cp:NeedSatisfier.
6    ?need  cp:hasNeedSatisfier  ?needSatisfier.
7    ?service  rdf:type  cp:Service ; cids:hasCode ?code ;
8        cp:providesSatisfier ?needSatisfier.
9}

Table 1 lists the first 5 services retrieved by the sample query. Every service retrieved can address at least one of the client’s needs via the satisfiers it provides, e.g., housing, addiction treatment, counseling.

service code
cp:S17-Female-Shelter cp:INST-Temporary_Shelter
cp:S10-1-Shelter cp:INST-Shelter
cp:S14-Housing-For-Homeless cp:INST-Housing
cp:S15-A0-Addiction-Services cp:INST-Addiction_Services
cp:S06-1-Counseling cp:INST-Counseling
Table 1: Client Need Q-3 SPARQL Query Results

[Client CQ-6] If I don’t like the program what are my other options? This question captures the situation where the initial service proposed to the client was rejected by them, and other service must be found that provides satifiers appropriate for their needs. The sample query assumes that the client is a homeless female residing in Area0, whose need is to improve her housing situation.

1SELECT DISTINCT ?service ?code WHERE {
2    BIND(cp:NS-Housing AS ?needSatisfier).
3    BIND(cp:Comp-Inst-Female-Homeless-Area0 AS ?compChar)
4    ?service  rdf:type  cp:Service ;
5        cids:hasCode ?code ; cp:hasRequirement ?compChar ;
6        cp:providesSatisfier  ?needSatisfier.
7}

Table 2 lists the services retrieved by the sample query. Every service retrieved provides housing and has as the eligibility conditions of being female, experiencing homelessness and residing in “Area0.”

service code
cp:S17-Female-Shelter cp:INST-Temporary_Shelter
cp:S10-1-Shelter cp:INST-Shelter
Table 2: Need Satisfiers-based Client Q-6 SPARQL Query Results

[Client Q-7.1] What are you going to do with my data in the program? This question requires listing of requirements for a particular service, namely cp:S06-1-Counseling, limited to codes instances of class cp:CL-Info_Privacy, that defines for data-privacy codes.

1SELECT DISTINCT ?service ?dataReq WHERE {
2    BIND(cp:S06-1-Counseling AS ?service).
3    ?dataReq rdf:type cp:CL-Info_Privacy.
4    {?service cp:hasRequirement [cids:hasCode ?dataReq].
5    } UNION {
6        ?service cp:hasRequirement [
7            rdf:type cids:CompositeCharacteristic   ;
8            oep:hasPart [cids:hasCode ?dataReq]]. }}   \end{lstlisting}
9
10\noindent
11In Table \ref{tbl:q7-1} we see that requirements related to information privacy, namely \textit{cp:INST-Doctor\_Yes} stating that a medical doctor needs access to the clients data, and
12\textit{cp:INST-Service\_Used\_Yes} stating the service itself needs access to the clients data.
13
14\begin{table}[ht]
15\centering
16\caption{Client Q-7.1 SPARQL Query Results}
17\label{tbl:q7-1}
18\begin{tabularx}{0.7\textwidth}{|X|X|}
19\hline
20\textbf{service}      & \textbf{dataReq}             \\ \hline
21cp:S06-1-Counseling & cp:INST-Doctor\_Yes        \\ \hline
22cp:S06-1-Counseling & cp:INST-Service\_Used\_Yes \\ \hline
23\end{tabularx}
24\end{table}
25
26
27    %###############################################################################
28%     \item[Q-7.2] Can the police or government access the system?
29%     \lstset{language=sparql}
30%     \begin{lstlisting}
31% SELECT DISTINCT ?service ?policeReq ?governmentReq WHERE {
32%     BIND(cp:S06-1-Counseling as ?service).
33%     ?dataReq rdf:type cp:CL-Info_Privacy.
34%     {?service :hasRequirement [cids:hasCode ?dataReq].
35%     } UNION {
36%         ?service :hasRequirement [
37%             rdf:type cids:CompositeCharacteristic   ;
38%             oep:hasPart [cids:hasCode ?req]]  .
39%     }
40%     BIND((?dataReq = cp:INST-Police_Yes) as ?policeReq).
41%     BIND((?dataReq = cp:INST-Government_Yes) as ?governmentReq).
42% }   \end{lstlisting}
43
44% \begin{table}[ht]
45% \centering
46% \caption{Q-7.2 SPARQL Query Results}
47% \begin{tabularx}{\textwidth}{|X|X|X|}
48% \hline
49% \textbf{service}      & \textbf{policeReq} & \textbf{governmentReq} \\ \hline
50% cp:S06-1-Counseling & false              & false                  \\ \hline
51% cp:S06-1-Counseling & true               & false                  \\ \hline
52% \end{tabularx}
53% \end{table}
54
55
56%———————————————————————————–
57% \subsection{Service Competency Questions}
58% \label{subsec:service-sparql}
59%———————————————————————————–
60
61
62    %###############################################################################
63\noindent
64\textbf{[Service Q-2]} \textit{How long did client \#2 stay in counselling?} This question queries \textit{cp:ServiceEvent} instances for entries related to client \textit{cp:Client2} accessing counseling services, identified by the service taxonomy code \textit{cp:INST-Counseling}. For each record found, it calculates the number of weeks between the data properties \textit{time:hasBeginning} and \textit{time:hasEnd}, indicating when the counseling services began and finished\footnote{Date arithmetic functions for \textit{ofn:} and \textit{spif:} defined at \url{https://graphdb.ontotext.com/documentation/9.10/free/sparql-functions-reference.html}.}. Finally, the sum of weeks is displayed in the \textbf{weeks} column of Table \ref{tbl:service-q2}
65
66    \lstset{language=sparql}
67    \begin{lstlisting}
68SELECT DISTINCT ?client ?weeks WHERE {
69    BIND(cp:Client2 AS ?client).
70    ?serviceEvent rdf:type cp:ServiceEvent ;
71        cp:forClient ?client ;
72        time:hasBeginning ?beg; time:hasEnd ?end;
73        cids:hasCode cp:INST-Counseling.
74    BIND((ofn:weeksBetween(
75        spif:parseDate(?end, "yyyy-MM-ddTHH:mm:ss.SSS"),
76        spif:parseDate(?beg, "yyyy-MM-ddTHH:mm:ss.SSS")))
77        AS ?weeks). }
client weeks
cp:Client2 43
Table 3: Service Q-2 SPARQL Query Results

[Outcome Q-1] What are the associated priority demographic groups? This question asks about the service usage of specific demographics, and to have them ordered by priority, where priority here means the largest population impacted. The query begins by identifying all clients that use services, as defined by the cp:ServiceEvent class in the knowledge graph. The results are accumulated by the stakeholder (?sh) each client satisfies. Here, the stakeholder is defined by characteristics defined by client taxonomy codes and the location they reside.

1SELECT ?loc ?sh (COUNT(?sh) AS ?count) WHERE {
2    ?serviceEvent rdf:type cp:ServiceEvent ;
3                  cp:forClient [cp:satisfiesStakeholder ?sh].
4    ?sh a cids:Stakeholder ;
5                 i72:located_in ?loc.
6    { ?sh cids:hasCharacteristic [cids:hasCode ?demo].
7    } UNION {
8        ?sh cids:hasCharacteristic
9            [ a cids:CompositeCharacteristic;
10                oep:hasPart [cids:hasCode ?demo]]
11}} GROUP BY ?sh ?loc
12ORDER BY DESC(?count)

In Table 4 we see a demonstrative sample of results summed by location (loc), stakeholder (sh), and code identifying the service type. The count columns displays the number of clients that satisfy a particular stakeholder definition at the location specified. For example, we see that 18 female, housed youth clients in location “Area0” use counseling services.

loc sh code count
cp:Area0_ Location cp:sh-Female-Housed-Youth-in_Area0 cp:INST-Counseling 18
cp:Area0_ Location cp:sh-Male-Youth-Addicted-in_Area0 cp:INST-Addiction_Services 15
cp:Area0_ Location cp:sh-Female-Adult-Addicted-in_Area0 cp:INST-Addiction_Services 9
cp:Area0_ Location cp:sh-Homeless-Male-Youth-in_Area0 cp:INST-Housing 6
Table 4: Outcome Q-1 SPARQL Query Results

8 Discussion and Conclusion

This paper introduces the Compass ontology and evaluates its ability to answer coverage-related competency questions. 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 service funding data. The questions discussed in the evaluation section were selected from a list compiled by subject matter experts on behalf of various social services stakeholders, including service clients, service providers, and those interested in long-term outcomes, such as service managers and funders.

Our evaluation demonstrates how coverage-related competency questions can be answered using the Compass ontology. Client-coverage queries identify clients that can use a service by listing requirements clients need to meet, the barriers they may face in meeting them, and offer alternatives when barriers cannot be overcome. Service-coverage queries successfully provide the cross-product service categories and targeted client populations. The queries also quantify resource usage and service availability over time. Such queries can provide information about specific services and clients or aggregate over categories of services and cohorts of clients based on client demographics, needs, and locations. Finally, the outcome-coverage queries answer questions similar to those about clients and services, but focus on the broader objectives of managerial and contributing stakeholders. These include obtaining quantitative information about the coverage of needs and highlighting potential gaps in service provisioning. These stakeholders can track their resources through the service-provisioning process across service categories, client cohorts, and locations.

Work continues on extending the client, service, and need taxonomies to ensure ontological concepts defined by Compass are shared and compared between organizations working towards similar or overlapping outcomes.

References