The Canadian Census of Population is a nationally administered questionnaire that is designed to collect socioeconomic data on the Canadian population. This census is mandated by law in the Constitution Act of 1867 to be conducted once every five years [1]. In the 2016 Census of Population, most households received the short form questionnaire that contains basic questions about the age, sex, marital status, etc. of members of a given household while approximately 25% of Canadian households received a long form questionnaire that also includes more detailed questions about education, employment, etc. The data that is collected from the census can be accessed and downloaded from Statistics Canada’s official website.¹

For the Canadian government, census data is necessary and valuable as the information is used for a wide variety of applications including calculating federal and provincial transfer payments, setting electoral boundaries, and supporting federal, provincial, and municipal government administration, planning, and policy development [2]. Census data also provides private sector organisations demographic insights into a geographic location of interest which could be useful for gauging consumer and market interest for various products and services.

The usefulness of census data can be greatly enhanced when integrated with other sources of data. For example, combining census data with transportation data, building data, zoning data, health data, etc. leads to significant insights, better policy, and operational decisions, as has been demonstrated by the plethora of data science applications developed over the last 10 years.² Yet it is known that integrating data from multiple sources requires significant effort. Data Wrangling, which includes the identification, cleansing and integration of data, takes approximately 70% of the time of a Data Science project [3]. Our goal is to facilitate the integration of census data by transforming it into semantically interoperable data. Semantic interoperability is the ability to exchange data with unambiguous, shared meaning. In doing so, we have to address two issues: referential equivalence and machine interpretable definitions of census characteristics/indicators.

The first issue is determining referential equivalence. How do we know that attribute names or the values of an attribute in two different datasets refer to the same thing? For example, if the name of a neighbourhood (or Ward, Census Track) in two different datasets are the same or similar (e.g., minor spelling difference), how can we be sure they refer to the same neighbourhood in the same city without access to meta-data that may specify the city covered by the data? Linked Open Data (LOD) standards address referential equivalence directly. Uniform Resource Identifiers (URIs) are unique, global identifiers that point to some specific information. If two different datasets contain the same URI, then they are referring to the same thing. For example, if dataset A contains information on census tract 5350001 and dataset B contains information on census tract 5350001.00, are both datasets referring to same geographic area? If both datasets use the same URI to represent the census tract, they are referring to the same geographic area.

The second issue is the lack of machine interpretable characteristic definitions. In the Canadian Census, a Characteristic, something to be measured in a census tract, is defined using natural language. For example, the characteristic “Total - Occupied private dwellings by structural type of dwelling - 100% data. To support reasoning about the characteristic, the definition would need to be deconstructed into its constituent concepts such “dwelling configuration,” “occupied,” “structural type” and structure types such as “private,” “dwelling,” “single-detached,” “house,” etc. By deconstructing the definition, questions can be asked spanning characteristics that refer to private dwellings or occupied dwellings across multiple characteristics. In other words, it is possible to answer questions that combine data from multiple characteristics, regardless of time and geography.

In the remainder of this paper, we will provide a brief introduction to the Canadian Census, a literature review of census ontologies and linked open data, our methodology and competency questions, the design of the Canadian Census Ontology, and example SPARQL³ queries and data visualisation applications.

The Canadian Census of Population is a survey that collects statistical information on the Canadian population and includes questions about age, sex, marital status, language, income, ethnicity, education level, dwellings, etc. The data from the census is anonymised and aggregated on various geographic levels (Figure 1) such as the national level (i.e., all of Canada), the provincial/territorial level (e.g., Ontario), the census metropolitan area level (e.g., Toronto), and the census tract level (i.e., small geographic areas that usually have a population between 2500 and 8000 persons).

Canadian Census data is published as Census Profiles for various geographic areas. For instance, there are Census Profiles for provinces (e.g., Ontario), cities (e.g., Toronto), and census tracts (e.g., census tract 5350001.00). Each of these Census Profiles consists of characteristics that are individual indicators describing the population that is being surveyed. For example, the “Total private dwellings” characteristic describes the total number of private dwellings that are located within a given geographic area. Some characteristics may also have additional numerical values for describing the male and female populations, in addition to the total population. For instance, the “In low income based on the Low-income measure, after tax (LIM-AT)” characteristic has a value for representing the total number of people who are in low income, a value for the number of males who are in low income, and a value for the number of females who are in low income.

Some characteristics that are found in the Canadian census can have one or more sub-characteristics that provide more specific or detailed information related to the parent characteristic. For instance, there is a characteristic for age groups in a given geographic area (Table 1). It contains separate sub-characteristics for age ranges 0-14, 15-64, 65+. The sub-characteristic 0-14 can be further subdivided into sub-characteristics 0-4, 5-9 and 10-14.

Table 1 depicts “Population and Dwellings” and “Age Characteristics” quantities as found in the StatsCan website.⁴

Ajani [4] advocates the standardisation of data using RDF⁵ and OWL,⁶ and the use of SPARQL for querying large datasets in order to address the issues of Volume, Variety, and Velocity associated with Big Data. Using census data as an example, Ajani explains that adapting semantic web technology could help integrate and standardise data from past, present, and future censuses, provide machine-readable metadata for census datasets, and enable convenient querying and extraction of desired data points from large datasets. Ajani believes that these benefits provided by this semantic web approach to distributing and disseminating census data would be helpful to governments and other organisations that use census data to make data-driven decisions.

To evaluate the quality of an open data system, Tim Berners-Lee [5], developed a five-star rating system for representing the core design principles for LOD. Open data with a one-star rating is defined as any data, in any format, that is available on the web with an open license (e.g., a scanned image of a data table). Open data that is in a machine-readable format (e.g., an Excel spreadsheet) is given an additional star for a total of a two-star rating. Open data can achieve a three-star rating if it additionally does not require the use of proprietary software to access (e.g., using comma-separated values (CSV) instead of Excel). Open data that uses W3C open standards, such as RDF and SPARQL, in addition to the above, get a four-star rating. Lastly, open data with a five-star rating contains all of the above while being linked to other LOD sources such as GeoNames or DBpedia.

Currently, the census data that is published on Statistics Canada’s website would be rated three stars under Tim Berners-Lee’s LOD rating system as it is available on the web with an open license and is also published in CSV format which is a non-proprietary format. From a referential equivalence perspective, StatsCan employs a Dissemination Geography Unique Identifier (DGUID) to identify geographic areas in the census datasets. The DGUID does not conform to URI standards, but could form a part of a URI. Similarly, census questions are numbered, but do not conform to URI standards.

In terms of machine-interpretable definitions, the CSV file lacks many things, including:

Ontologies and linked data can help enable the integration of census data with other data sources, allow for complex querying and visualisations, and improve the accessibility of the data [6]. For these reasons, there have been a number of efforts toward publishing census data as Linked Open Data (LOD).

Census data is often used with other data sources for analytical and statistical research. For instance, census data combined with energy use data can be used to estimate energy access in different regions of a country in order to track progress towards the United Nations Sustainable Development Goal 7 [7]. Combining census data with mortality rates across socio-economic classes could elucidate possible trends in health and social inequalities between individuals of different socio-economic status [8]. Data from child hospitalisations due to abuse can also be combined with census data to estimate the incidence rate of physical abuse among children of different ages [9]. However, as censuses are generally conducted only once every 5 or 10 years [10], the time periods for the census data may be different from the time periods for the other data sources of interest. Oftentimes intercensal estimations are used to approximate data values for years between censuses, as seen in the three examples mentioned above. National statistical agencies may publish their own intercensal/postcensal estimates but other times, researchers may have to conduct their own estimates for their populations of interest. Assuming a constant rate of change between census years (linear interpolation) may be sufficient for approximating an intercensal data point although these estimates may be inaccurate when populations experience sudden changes (e.g., natural disasters) [11] or when the population of interest is too small [12].

Intercensal estimates may be adequate when combined with an additional dataset from a different time period. But when several datasets, each from different time periods, are being combined, then an approach unique to the data being combined, is required. In such a situation it is important to document the assumptions made about the method and validity of the inter-temporal estimates.

Statistics Canada provides a Linkable Open Data Environment (LODE) for public access of municipal, provincial, and federal data [13]. “Linkable” in the context of Statistics Canada’s LODE refers to how the databases in the LODE are published under a single open data license and the data can all be processed and visualised using the same set of open-source tools⁷ provided by Statistics Canada. This does not mean that the data in the LODE is published as Linked Open Data. Currently, Statistics Canada’s LODE consists of six open databases: The Open Database of Buildings (ODB), The Open Database of Educational Facilities (ODEF), The Open Database of Healthcare Facilities (ODHF), The Open Database of Cultural and Art Facilities (ODCAF), The Open Database of Addresses (ODA), and The Open Database of Recreational and Sport Facilities (ODRSF). LODE datasets use libpostal, a natural language processing solution, to separate address information into its individual components (e.g., street name, street number, city name, etc.) and addresses that did not have geocoordinates are geocoded using geocoders like ESRI ArcGIS Online (AGOL) and OpenStreetMap Nominatim geocoder. The ODB is published in Geographic Information System (GIS) format while the other five databases are published in CSV format. Although Statistics Canada has invested significant efforts into geocoding their data, they currently do not have a formal ontology for the semantic representation of geospatial information. Statistics Canada’s LODE also includes their LODE Viewer tool which uses information from the above databases to provide the locations of healthcare facilities, cultural/art facilities, educational facilities, and recreational/sport facilities along with a map overlay of building footprints. Although Statistics Canada claims that they aim to harmonise data from different sources, their LODE initiative does not incorporate census data at this time [13]. Furthermore, Statistics Canada does not currently provide an ontology for representing the statistical data nor URIs in their LODE.

While Statistics Canada’s LODE is an important initiative towards publishing and disseminating open government data, it is not “linked” in a semantic web context as entities, attributes, and values (where appropriate) are not specified using URIs, nor are the textual definitions machine interpretable, and they are not published using semantic web standards such as RDF and OWL.

Bukhari and Baker [14] provided a SPARQL endpoint for querying purposes in an effort to encourage the use of new and up-to-date data for critical, health-related decision-making. For this project, Bukhari and Baker opted to use D2RQ,⁸ a system for accessing relational databases as RDF graphs, to transform the data from the Canadian health census into LOD. With this approach, the authors provided a semantic mapping of Cancer Survival Patients by mapping the entities in the dataset to analogous concepts from well-known semantic ontologies using D2RQ. For example, the authors used the foaf:age property to represent the age of cancer survival patients as an integer and the foaf:gender property to represent the patients’ gender as a string, as seen in their semantic mapping (Figure 2). Bukhari and Baker explain that publishing the data from the Canadian health census as LOD could help enhance timely decision-making processes and optimise the provision of health services by identifying geographic regions that experience higher than average cases of treatable-disease deaths and could also be used to correlate data across datasets (e.g., finding a negative correlation between breast feeding and breast cancer).

Census data is often published as aggregated data across geographic areas of interest in order to protect the privacy of individuals. Nevertheless, some census organisations also provide census microdata (i.e., data on the individual level) for academic uses. This data is usually closed and available with restrictions. For example, Statistics Canada’s Research Data Centres⁹ provide access to microdata only within their physical centre (i.e., no online access), and all analyses must be performed on their computers. Only the results of the analysis may be removed from the facility. As such, most of the existing academic work is focused on using aggregated census data while other academic projects might focus on census microdata instead. For example, the IPUMS project has been collecting and distributing census microdata for over 100 countries across 547 censuses and surveys for qualified researchers to use [15]. In the following, we review existing approaches to representing both aggregated census data and microdata as LOD.

Petrou et al. [16], defined a framework (Figure 3) for publishing the 2011 Greek aggregated census data as LOD, using the Resource Description Framework (RDF) data model, in order to improve the accessibility of statistical information. In their project, they mapped the Greek census data, which contained demographic data about the Greece population (e.g., sex, marital status, education level, etc.) and data about households and dwellings (e.g., building type, number of bedrooms, etc.), onto the Data Cube Vocabulary.¹⁰’ To do this, the dataset as a whole was mapped to the qb:DataSet class and the columns in the dataset were mapped to the appropriate concepts in the Data Cube schema. They identified the column with the regional divisions (which are represented using geocodes) to be their dimension and accordingly mapped this concept to the qb:DimensionProperty class. The population column was identified as the measure, so this column was mapped to the qb:MeasureProperty class. Lastly, the unit of measurement (number of habitants, in this case) was mapped to the qb:AttributeProperty class. This approach allowed them to link an indicator (e.g., population of geocode 0102) to its numerical value (e.g., 16577), its geocode (e.g., 0102), and the dataset that the indicator belongs to (e.g., Permanent residence population census 2011).

Similarly, Aracri et al. [17] also worked on a similar project where they provided an approach for publishing the 15th Italian Population and Housing Census using LOD as a part of the Istat’s (Italian National Institute of Statistics) Linked Data dissemination strategy. Like Petrou et al. [16], they were also interested in representing aggregated census data as LOD and also adopted the RDF Data Cube Vocabulary for translating census data to LOD. With the Data Cube Vocabulary, Aracri et al. provided a framework for representing a census indicator (e.g., “number of resident male age between 45 and 49 years”) and linking it to its corresponding dataset, census section (i.e., location), census year, indicator value, etc. (Figure 4). However, unlike Petrou et al., they map the census indicators to qb:Observation while using their own attributes to describe the indicator. These attributes include census:Year (to describe the year of the census indicator), census:Sex (to describe the sex of the population that is being represented), census:AgeClass (to describe the age range of the population that is being represented), census:Citizenship (to describe the citizenship status of the population that is being represented), census:ResidentPopulation (to describe the numerical value of the indicator), and territory:CensusSection (to describe the geographic area that the indicator represents). With these attributes, Aracri et al. were able to represent and describe Italian census population data according to territory, sex, age class, etc. while linking each indicator back to the census dataset that they can be found in. Their ontological representation does not deconstruct and represent the definition of the indicator nor capture the units of measure for the indicator (i.e., population counts in this case).

To extend the Istat’s LOD initiative, Aracri et al. [18] created an ontology for modeling data from the Istat’s Base Statistical Registers (BSRs) which include Persons, Families, and Cohabitations. Unlike the previous two projects that were focused on the representation of aggregated census data, they developed a microdata approach to represent BSR data as it contains information about individuals. Their ontology is expressed in OWL2 and provides a standard for representing the relationships between people (e.g., parentOf, son/daughterOf) and their residences. The main classes in this ontology are Person (represents a single person), Family (represents a group of persons bound by marriage, kinship, etc.), Nuclear Family (represents a group of persons forming a couple relationship or parent-child type), and Cohabitation (represents a group of persons who live together, without being bound by marriage, kinship, etc.). Aracri et al. expressed that they aim to integrate this ontology with the census ontology outlined in the Aracri et al. [17] report in the future in order to effectively integrate and disseminate Istat data from multiple different sources.

Fernández et al. [6] provide another example of modeling microdata as they developed an RDF scheme for representing the microdata from the 2001 Spanish Census. Using this approach, Fernández et al. were able to represent the characteristics of an individual (e.g., birth year, birthplace), familial relations between individuals in a family nucleus (e.g., mother-child relationship), and identify the home/building that these individuals lived in (Figures 5, 6). To demonstrate the practicality of their work, the authors also created SPARQL queries that aggregate the microdata to show the total number of Spanish and foreign people per age and visualised the results as graphs and figures using the Google Visualisation API.

This review demonstrates that there is an increasing need and interest in representing and publishing census data using ontologies and LOD. While there have been several different approaches to modeling census data in European countries such as Greece, Italy, and Spain, there is little existing work on modeling the data found in the Canadian Census of Population.

There are four notable issues with translating Canadian census data. Firstly, there is a lack of unique identifiers for census characteristics at aggregate and tract level and there needs to be a unique name for each characteristic in order to ensure that each characteristic has its own unique URI.¹¹ Secondly, there is a lack of a hierarchical representation of spatial areas and there needs to be some consistent way of representing the relations between geographic areas. Thirdly, there is a lack of a semantic representation of the definitions of census characteristics. Finally, there needs to be a standardised method for representing these characteristics on the semantic web. The existing census ontologies do not provide a simple way to aggregate census data from smaller geographic regions (e.g., census tracts) into data for larger geographic areas of interest (e.g., city, neighbourhood, ward). This is particularly important as governments and other organisations may need to make decisions and plan their operational work on a city/neighbourhood/ward level instead of the census tract level. The third issue has also not been addressed by existing work, namely how to represent the definition/meaning of a characteristic/indicator. The aim of this work is to fill the gap in existing literature in order to address these issues and translate the information in the Census of Population into RDF format and publish Canadian census data as ontology-based LOD.

We use the methodology defined in Grüninger & Fox [20] to engineer the Canadian Census Ontology. The process begins by defining a set of usage scenarios. Based on the scenarios, we identify a set of competency questions that the ontology must answer. These are the requirements for what is to be represented and the deductions to be performed. We analyse these questions to determine groupings (categories), frequency of occurrence, and importance to the city’s operation. The usage scenarios and competency questions are derived from these.

The next step of the process is to review existing ontologies to ascertain the extent they satisfy some or all of the competency questions. Relevant concepts and properties are candidates for inclusion in the final ontology. Next, the terminology (i.e., concepts and properties) required to answer the competency questions are defined. The semantics of the terminology are defined by constructing a set of axioms that define and/or constrain their interpretation. The axioms are important as they precisely define the terms, and can determine whether the data that underlies the terms are consistent. As part of this step, we identify and create ontology modules (aka microtheories¹²) that are foundational to the operations of a city. These microtheories form the building blocks for more specific city data. For example, many city applications rely upon the recipient of a service to be a resident of the city. What does it mean to be a resident? What are the necessary and sufficient conditions for residency? What are the core concepts and properties that should be used to construct a theory of residency? How are these concepts and properties defined (i.e., axiomatised)? Residency is just one of many other foundational ontologies that are expected to emerge during our research.

Finally, the ontology is evaluated based on the extent to which the ontology is able to answer the competency questions. The evaluation of the axioms with respect to the competency questions is supported through the use of automated theorem provers, following the work of Katsumi and Gruninger [22]. We can therefore claim and formally verify the correctness and completeness of an ontology with respect to its requirements.

In order to develop an ontology that is capable of representing census data in a useful and meaningful way, we must first understand how census data might be used by governments or other organisations. Census data can be used for a wide variety of academic, commercial, or governmental purposes. For instance, census data is often used by government organisations for evaluating and improving their social service programs [2]. As managing and improving community services is a crucial part of the government’s operations, we have identified the following use cases and competency questions in the context of improving local neighbourhoods and their social services for the municipal government of Toronto.

In Toronto, the municipal government uses multiple sources of data (including census data) to evaluate the social and economic well-being of its neighbourhoods. In 2020, the Toronto municipal government had identified 33 Neighbourhood Improvement Areas (NIAs) which are vulnerable districts within the City that require additional social and economic support. To elaborate, the City uses the Urban Health Equity Assessment and Response Tool (HEART) to score neighbourhoods under five domains of neighbourhood well-being [23] and NIAs are the neighbourhoods with scores that fall below the designated Neighbourhood Equity Benchmark. These five domains are Economic Opportunities, Social Development, Participation in Decision Making, Healthy Lives, and Physical Surroundings. Economic Opportunities refers to the economic status of the neighbourhood and the income levels and job opportunities that its residents have access to. Social Development refers to providing neighbourhood residents with access to social, recreational, and cultural services as well as resources for residents to improve their education and literacy. Participation in Decision Making refers to providing residents with opportunities to get involved with local decisions such as voting in elections. Healthy Lives refers to the physical and mental health of neighbourhood residents and their access to medical care resources. Lastly, Physical Surroundings refers to the natural and built environment of the neighbourhood, including public spaces, transportation infrastructure, and air quality.

After the NIAs are identified by the Urban HEART @Toronto Project Team, Neighbourhood Planning Tables are formed to represent and manage the social programs of the NIAs. These Neighbourhood Planning Tables consist of local residents, businesses, community agencies, City Councilors, and City staff who coordinate and cooperate to develop Neighbourhood Action Plans that are best suited for the social and economic conditions specific to each NIA. Data from the Canadian census could be used to help these Neighbourhood Planning Tables identify high priority issues in the NIA and help them design and deploy social programs that better meet the needs of the neighbourhood’s demographics. In the following, we formulate competency questions (CQ) for retrieving census data relevant to the HEART domains that could be useful for the Neighbourhood Planning Tables’ planning and implementation of action items. These competency questions can also help us evaluate the capability and usefulness of the Canadian Census Ontology in the example context of improving and managing NIAs in Toronto.

Additionally, NIAs may need to analyse and manage geographic areas that partially overlap with multiple census tract areas. As such, they may need to aggregate census data in a geographic area that cannot be simply expressed as a sum of census tracts. In these cases, it would be useful to know how much the designated area overlaps with the census tract boundaries in order to calculate a weighted average for the desired census data.

This section defines an ontology representing census data and related information. Ontologies allow us to model information by providing a formal way to define and represent entities, their attributes, and the relations among entities. Ontologies are composed of two main elements: classes and properties. A Class defines, by means of a formal, logical language, a concept in relation to other concepts in the domain. Classes can also have zero or more properties that are used to link classes to other classes (i.e., object properties) or literal values (i.e., data properties). Ontologies also include axioms that are used to define classes as logical combinations of their properties. In addition, ontologies may contain instances. Instances that satisfy the definition of the class may be inferred to be members of that class, and conversely members of the class are required to satisfy the definition of the class. For example, a CensusTract class would be the class that represents the set of all individual census tracts (e.g., census tract 5350001.00). While there are multiple different languages for expressing ontologies, the Canadian Census Ontology described in this paper is defined using Web Ontology Language (OWL 2) is detailed in this section and can be accessed using the following URL: https://github.com/EnterpriseIntegrationLab/CKGN/tree/main/UniversityOfToronto/Census/Ontologies. Furthermore, a table of key classes and properties can be found in Appendix I.

The Canadian Census ontology is defined using OWL2.²⁰ The ontology, and the census data instances of the ontology, are represented as a knowledge graph using RDF. The knowledge graph can be queried using SPARQL (SPARQL Protocol and RDF Query Language), a RDF query language.²¹ In this section, we translate competency question CQ3, defined in Section 4, into a SPARQL query to demonstrate the competency of the census ontology. The remainder of the competency questions’ translations can be found in Appendix II.

We use the Southeast Scarborough Planning Table and the 2016 Canadian Census data for its four neighbourhoods it is responsible for (Neighbourhoods 135 (Morningside), 136 (West Hill), 137 (Woburn), 139 (Scarborough Village)) as an example for the queries in this section.

CQ3: Which NIAs have the most low-income residents?

The following query finds the value of the characteristic “In low income based on the Low-income measure, after tax (LIM-AT)” (depicted in Figure 18) for the census tracts in the designated neighbourhoods and outputs a table that displays the neighbourhood in one column and the summed value of the characteristic across all the census tracts in that neighbourhood in another column. This LIM-AT characteristic is represented by the “LowIncomeMeasureAfterTaxPercent2016”class which is a subclass of Characteristic. This query could help Neighbourhood Planning Tables identify the neighbourhoods that have the highest number of low-income citizens. The diagram below illustrates some of the classes, properties, and instances used in this query.

By running the SPARQL query, we can see (Figure 19) that out of all the NIAs managed by the Southeast Scarborough Planning Table, Neighbourhood 137 (Woburn) has the highest number of low-income residents (14410) while Neighbourhood 135 (Morningside) has the lowest number of low-income residents (4085).

Similar queries can be constructed to answer the remaining competency questions, which can be found in Appendix II.

Building the_ Canadian Census Ontology on top of the ISO/IEC 5087 and ISO/IEC 21972 standards allows us to integrate the data from the Canadian Census with other datasets that have been mapped onto these standards. For example, we have mapped Toronto’s neighbourhood crime data published by the Toronto Police Service²² onto the ISO/IEC 21972 indicator ontology and the ISO/IEC 5087 ontologies (i.e., police precinct areas are represented as administrative areas), allowing the dataset to be integrated with the Canadian Census data. This integration supports analyses exploring links between crime and socioeconomic factors. We have also mapped subsets of OpenStreetMap²³ data including roads, buildings, stores, etc. onto ISO/IEC 5087-1, -2 and -3. Integrating OpenStreetMap data with the census data supports the analysis of infrastructure, retail, commercial, etc. environments in relation to the socioeconomic data found in the census. Furthermore, the integration with other datasets allows users to use SPARQL queries to access data from multiple different sources without needing to deal with the different file formats that the datasets were originally published in.

Another advantage of publishing census data as linked data is that it enables researchers and analysts to build their own data analysis and/or data visualisation tools that can process the data in the knowledge graph. In fact, the Canadian Census Ontology supports a general approach for visualising metrics for any administrative area as it includes representation of geospatial data that can be linked to census data. For example, a Python program that utilises existing data visualisation packages (such as Folium) can be used to easily generate interactive choropleth maps using census linked data. An example of such visualisation is shown in Figure 20 below:

This choropleth visualisation shows a map of Toronto, and its neighbourhoods which are colored based on the number of unemployed individuals in that neighbourhood. Yellow represents fewer unemployed individuals while red represents more unemployed individuals. A popup box that shows the neighbourhood name and the number of unemployed individuals also appears on mouse hover. This map was created using the CensusVis program²⁴ that was developed as a project under the University of Toronto’s Enterprise Integration Laboratory. This program is capable of generating choropleth maps using linked data that is queried (using SPARQL queries like the ones seen in Section 7.0) from the knowledge graph and supports the visualisation of census data in various types of administrative areas. CensusVis enables easy creation of data visualisations as the user only needs to input the type of administrative area to be visualised (e.g., wards, neighbourhoods, etc.) and the class name of the census characteristic to be visualised (e.g., ”Unemployed2016“ for the number of unemployed individuals) in order to generate a choropleth map of the selected administrative area and census characteristic. Similar visualisations could also be created for other cities and administrative areas if they are published as linked data using the Canadian Census Ontology.

The goal of our research is to “open up” census data by reducing the complexity and ambiguity inherent in integrating census data with other data sources. Complexity arises out of having to deconstruct census characteristics (metrics) definitions into their constituent concepts, in order to understand how it may relate to other data sources. Ambiguity arises in the imprecision in the definition of potentially relevant data (both attributes and values) found in other sources. Our approach is based on three technologies:

Our approach to deconstructing census characteristic natural language definitions is to map the concepts embedded in a definition onto the ISO/IEC 21972 Indicator ontology that provides semantics for defining statistical populations. These populations are, in turn, defined by prototypical descriptions of members of the population. For example, prototypical description of a household, person, dwelling, etc. The representation of these prototypical descriptions is based on ontologies such as the ISO/IEC 5087 series of city data standards, which includes concepts and properties for the representation of households, person, dwellings, municipal administrative areas, etc.

The resulting knowledge graph is an integration of the multiple data sources, providing direct and indirect connections across the data/concepts contained therein. Using query languages such as SPARQL, complex relationships amongst the data can be explored and visualised without the cost of additional data wrangling.

With the completion of the ontology, we are pursuing the use of AI Large Language Models (LLM) for mapping census characteristic definitions onto our ontology and using LLMs as a natural language query interface for generating SPARQL queries for the knowledge graph.