Common Impact Data Standard

Acknowledgements back to ToC

The Common Impact Data Standard Version 3.1 was updated by:

• Derek Laventure, Consensus Enterprises, https://consensus.enterprises/
• Garth Yule, Common Approach to Impact Measurement, https://www.commonapproach.org/
• Kate Ruff, Common Approach to Impact Measurement, https://www.commonapproach.org/

Version 3.1 was supported, in part, by the Government of Canada’s Social Finance Fund.

The Common Impact Data Standard Version 3.0 was updated by:

• James Arruda, Indigenous Youth Roots, indigenousyouthroots.ca
• Sharad Barkataki, Common Approach to Impact Measurement, commonapproach.org
• Chantal Buard, Impact Atlas, impactatlas.com
• Sylvain Carle, Canadian Investors / Venture Impact Coalition, coalition-impact.ca/
• Alex Castner, threshold.world and b.world
• Mark Fox, Centre for Social Services Engineering, University of Toronto, csse.utoronto.ca/
• Bart Gajderowicz, Urban Data Consultancy and University of Toronto, csse.utoronto.ca
• Murat Kantarcioglu, The University of Texas at Dalla, utdallas.edu/
• Art Law, TAS Impact, tasimpact.ca
• Daniela Rosu, University of Toronto, csse.utoronto.ca.
• Kate Ruff, Common Approach to Impact Measurement, commonapproach.org
• Alex Pittman. ImpactMapper, impactmapper.com
• Robert Warren, Common Approach to Impact Measurement, commonapproach.org
• Liz Wilson, ANZ Bank and Metataxis.com
• Garth Yule, Common Approach to Impact Measurement, commonapproach.org

Version 3.0 was supported, in part, by the Government of Canada’s Social Finance Fund.

The Common Impact Data Standard Version 2.1 was updated by

• Alicia Richins, Common Approach to Impact Measurement, commonapproach.org
• Mark Fox Centre for Social Services Engineering, University of Toronto, csse.utoronto.ca
• Alex Goel, Logical Outcomes
• Dan Lammot, threshold.world and b.world
• Jaclene Roshan, Salesforce Nonprofit Cloud
• Kate Ruff, Common Approach to Impact Measurement, commonapproach.org

With contributions from Meg Gray, Salesforce; Jess Peters and Derek Hatchard, Riddl; Seonaid Lee.

Version 2.1 was supported, in part, by the Government of Canada’s Investment Readiness Program.

Version 1.1 was principally authored by

• Mark Fox Centre for Social Services Engineering, University of Toronto, csse.utoronto.ca
• Kate Ruff, Common Approach to Impact Measurement, commonapproach.org
• Bart Gajderowicz Centre for Social Services Engineering, University of Toronto, csse.utoronto.ca
• Anshula Chowdhury, Sametrica, sametrica.com
• Tawfiq Abdulai, Sametrica, sametrica.com
• Jane Zhang, Centre for Social Innovation, socialinnovation.org

With contributions from: James Hicks and Spencer Powell, Impact Management Project, and Daniela Rosu, University of Toronto.

Version 1.1 was supported, in part, by the Ontario Ministry of Economic Growth and Development and the Government of Canada Investment Readiness Program.

Common Impact Data Standard V3.0 © 2025 by Common Approach to Impact Measurement is licensed under CC BY-SA 4.0. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.

The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing Widoco, the program used to create the template used in this documentation.

Revision History

Revision	Date	Changes
1.1	20 November 2020	Removed import of Common Approach Vocabulary (cav) and all uses of it in the ontology.
		Combined Foundation and Core Ontology into a single document now called the Common Impact Data Standard.
		Added ImpactReport to separate reporting of indicators and outcomes.
		Moved “How Much” IMP information from StakeholderOutcome to the Outcome Report (Now ImpactReport) and added link from StakeholderOutcome to ImpactReport.
		hasSize in Outcome changed to hasImpactScale.
		hasSize, hasDepth and hasDuration properties moved to ImpactReport. For clarity, they were renamed ImpactSize ImpactDepth and ImpactDuration.
		Stakeholder properties added: sch:name (title), sch:description, hasCatchmentArea and hasStakeholderCharacteristic.
		hasThreshold and has Access added to Indicator.
		The value of i72:value property changed to i72:Measure.
		hasAmount changed to i72:value in Output class.
	24 November 2020	Removed “benefitsFrom” property from ContributingStakeholder.
	26 November 2020	Added Quality measures. Added ddqv:target only dqv:QualityPolicy to Indicator. Added dqv:hasQualityAnnotation, dqv:conformsTo and dqv:hasQualityMeasurement to IndicatorReport.
	28 November 2020	Replaced Dataset with dcat:Dataset. hasImportance in StakeHolderOutcome changed to a dataproperty. Deleted ImpactImportance class. Domain revised to support reference to an external standard/codelist – UNSDG example added. ImpactReport hasMethod replaced by prov:wasGeneratedBy. Change hasCatchmentArea to data property. Deleted CatchmentArea class. In Indicator, replaced hasDataSource with dqv:dataset; replaced Dataset class with dqv:Dataset; replaced hasMethod with prov:wasGeneratedBy:.
1.2	20 January 2021	Added object property hasTimeInterval. Added “hasTimeInterval only DateTimeInterval” to ImpactReport.
		Added “hasImpactReport only ImpactReport” to Outcome.
		Changed hasIndicator to forIndicator in ImpactDepth, ImpactDuration and ImpactScale.
		In ImpactDuration replace hasStartTime and hasEndTime with “hasTimeInterval exactly 1 time:DateTimeInterval”.
		In ImpactNorms, added “hasIndicatorReport only IndicatorReport”.
	22 January 2021	Replaced in IndicatorReport i72:for_time_interval with hasTimeInterval (functional).
		Added time:DateTimeDescription class to Section 3.1, with value restriction on hasBeginning and hasEnd being time:DateTimeDescription.
		Added org:hasName to ImpactReport.
		Replaced schema:description with hasDescription – defined as a functional subproperty of schema:description.
		Replaced schema:name with org:hasName– defined as a functional sub-property of schema:name.
		Replaced schema:identifier with org:hasIdentifier– defined as a functional subproperty of schema:identifier.
	15 February 2021	Added forStakeholder object property to StakeholderCharacteristic.
		Added SocialPurposeOrganization, FinancialOrganization and StandardsOrganization as subclasses of Organization.
		Updated prefix list in Table 3.
		Changed value restriction of hasOccupation in Person to xsd:string.
	13 May 2021	Added codeValueDescription to Domain Class in Outcome section.
		Updated the JSON-LD example in Section 4 to use the latest context definition files.
		Changed value restriction of forOutcome in ImpactReport to “exactly 1 StakeholderOutcome”.
		Added “time:hasTime exactly 1 time:DateTimeInterval” to ImpactReport.
		StakeholderCharacteristic: Renamed Characteristic. Replaced hasStakeholderCharacteristics with hasCharacteristic.
	27 June 2021	Added “forOutcome exactly 1 Outcome” to StakeholderOutcome in order to identify which outcome it is associated with.
		Updated Common Impact Data Standard graph.
		hasImpactReport now appears in both Outcome and StakeholderOutcome.
		Added Code a a generic class to refer to standards defined by other organizations, e.g., indicators, outcomes, characteristics, etc.
		Added hasContact to cids:Organization.
		BeneficiaryStakeholder renamed to BeneficialStakeholder.
		Impact scale, duration, depth generalized into HowMuchImpact.
2.0	August 2021	Added graphs to sections.
	14 November 2021	All prov:wasGeneratedBy value restrictions changed to Activity.
2.1	23 February 2022	Minor miscellaneous corrections.
	1 March 2022	Change Stakeholder so it is no longer a subclass of Person or Organization.
	1 April 2022	Add hasDescription to Characteristic.
	27 April 2022	Removed hasCharacteristic from LogicModel.
	18 August 2022	Added reference to linked data in 1.3. Added “hasLocation only Feature” to cids:Organization. Added JSON-LD explanation.
	20 January 2023	“Domain” renamed “Theme”. Added internally derived themes to the definition of Outcome Themes. In IndicatorReport, opened up prov:Generated by value restriction to capture more than one method.
	April 2023	Added gn:Feature so that a Stakeholder can be an organization, person, or feature, such as the planet, a river, or a forest. Updated all Figures Minor miscellaneous corrections.
3.0	May 2024	Changed value restriction on forOrganization property of ImpactModel from “exactly 1” to “only”. Added geo prefix to Appendix 2. Renamed hasMission property in Organization to hasPurpose. Added hasStakeholder to Organization to identify stakeholders associated with the organization. Added descriptions of the properties org:issuedBy. Added forOrganization to Outcome to identify the Organization associated with an outcome. Added i72:unit_of_measure to Counterfactual, to capture the units of measurement of the counterfactual. Added i72:unit_of_measure to HowMuchImpact to capture the units of measurement of the impact. Added relatesTo property to Theme to allow linking between Themes. Revised description of Theme. Added forOrganization to Stakeholder. Minor miscellaneous corrections and edits of figures.
		Added a new class called Target with the following properties: hasName: Specifies the target’s name. i72:value: Specifies a single measure of the target. I72:unit_of_measure: Specifies a unit of measure for the target. time:hasTime: Specifies the time interval that the target covers. hasComment: A string property in which a general comment for the target can be specified. sch:dateCreated: Is the date that the target was created. forIndicatorReport: Links to the IndicatorReports which are associated with the target.
		Replace dqv:target in Indicator with a new property hasTarget, that references a new class Target. Added forOrganization to Indicator. Added i72:unit_of_measure to Indicator to capture the units of the Indicator. Added hasTarget to Indicator to capture the Targets associated with the Indicator Added description of sch:dateCreated to Indicator. Added i72:unit_of_measure to IndicatorReport to specify the units of the IndicatorReport. Added forTarget to IndicatorReport to link the result value to a specific Target.
		Renamed LogicModel to ImpactPathway. Added hasIndicator to ImpactPathway. Added hasIndicatorReport to ImpactPathway. Removed ImpactNorms class.
		Changed value restriction of forIndicator in HowMuchImpact from “exactly” to “only” to allow it to reference the number of Indicators that may be used to calculate scale, depth, and duration. Added canProduce property to Output class to link an Output to an Outcome.
		Added a new section (Section 1.5) on how software can align with the standard. Updated requirements for alignment at Basic and Essential Tiers. Added a description to the introduction of how JSON-LD is to be used for the standard.
		Added a new class, StakeholderReport, with the following properties: forStakeholder: Specifies the stakeholders for which the report is being generated. time:hasTime: Identifies the time interval of the stakeholder report. hasCharacteristicReport: Specifies the characteristics reports associated with the selected stakeholders. hasPerson: Identifies the persons who are the stakeholders being reported upon. forOrganization: Identifies the organization for which the stakeholder report is being generated.
		Added a new class, CharacteristicReport, with the following properties: forCharacteristic: Identifies the characteristics for which the report is being generated. numberOf: Species the number of members which possess the characteristics.
	June, 2024	Simplified ImpactPathway Removed hasResource from ImpactPathway.
		Aligned OutcomeChain and Basic Tier Removed hasActivity from OutcomeChain. Added hasOutput and hasTheme to OutcomeChain.
	September, 2024	Created a complementary document to contain implementation guidance for developers with topics including URI format, time format, guidance for create/update/delete of records, handling files containing data for multiple organizations, and other implementation issues not strictly in the domain of the ontology itself. Added Counterfactual property to Indicator class Added hasCode to Theme class at Basic Tier In Code class, changed org:hasIdentifier with value restriction exactly 1 org:identifier to hasIdentifier with value restriction max 1 cids:identifier Revised hierarchy so that Organizations have Programs that have LogicModels. Added hasProgram to Organization class, removed hasImpactModel from Organization class, added hasImpactModel to Program class. Replaced time:hasTime property with value restriction of exactly 1 time:dateTimeInterval with two properties: prov:startedAtTime and prov:endedAtTime, each with value of exactly 1 xsd:dateTime. This considerably simplifies reporting time intervals while retaining flexibility to use the OWL time ontology if needed. Noted for readers in two sections that the terms “metric” and “indicator” are used interchangeably throughout. Fixed various typos and minor errors.
3.1	June 2025	From version 3.1 forward, the data standard files and explanatory guide are managed in a public repository in Github and use Semantic Versioning; this version (3.0 to 3.1) is a Minor release. This release repairs discrepancies in the OWL ontology file so that it accurately represents the contents of the authoritative PDF document that describes version 3.0 of the data standard.
		For the classes and properties at the Basic and Essential Tiers, the majority of edits were to add complete and accurate data to rdfs:name and rdfs:label properties, which will make using and interpreting the data standard a little friendlier. The changes for version 3.1 are summarized by Alignment Tier below. For more detail, the full commit history is available through Issues #46-76 in the Common Impact Data Standard Github repository.
		General changes
		Ontology Structure & Formatting: Fixed OWL header and syntax issues (#46). Adapted OWL file to Protégé formatting, including minor fixes resulting from Protege import/export (#48).
		General Property Consistency: Reset all hasName and hasDescription properties to have a value restriction of exactly 1 xsd:string, incorporating rdfs:comment and rdfs:label into main class definitions (#69).
		Changes relevant to Basic Tier and SFF classes and properties
		Normally some of the increases in restrictions (max 1 to exactly 1) would indicate a Major change, but in this case it was a repairing uncaught omissions in the OWL file where the property restrictions were not updated at the time of the release of v.3.0, and where most developers were referring to the PDF rather than the OWL file for the restrictions.
		Characteristic Class: Corrected rdfs:comment, updated dc:description, removed redundant rdfs:label and hasName properties, and converted time:hasTime to separate start/end time properties for the Characteristic class (#61).
		Code Class: Fixed description text and adjusted hasIdentifier restriction from exactly 1 to max 1 (#50).
		Indicator Class: Fixed rdfs:comment, added forOrganization property, and fixed restrictions (#64).
		IndicatorReport Class: Added some missing property declarations, missing class restrictions, and fixed rdfs:comment (#65).
		Outcome Class: Fixed cardinality of forOrganization from max 1 to exactly 1, and corrected rdfs:comment (#52).
		Theme Class: Corrected rdfs:comment (#53).
		Changes relevant to Essential Tier
		CharacteristicReport Class: Added missing rdfs:comment and included rdfs:subClassOf cids:Thing (#63).
		StakeholderReport Class: Corrected rdfs:comment, converted time:hasTime to start/end time properties, and replaced hasCharacteristic property with hasCharacteristicReport (#62).
		ImpactReport Class: Added consistent rdfs:comment and replaced time:hasTime with prov:startedAtTime and prov:endedAtTime, including new data property declarations (#55).
		Indicator class: Replaced dqv:target with hasTarget property.
		Organization Class: Replaced hasImpactModel with hasProgram property, added hasStakeholder property, and ensured rdfs:comment and rdfs:label are consistent with PDF documentation (#51).
		Outcome Class: Replaced hasImpactRisk with hasImpactReport Stakeholder Class: Updated rdfs:comment and fixed some property restrictions (#60).
		BeneficialStakeholder: Replaced hasRole object property with hasImpactManagementNormsDefinition datatype property, and removed extraneous Stakeholder subclasses (#76).
		StakeholderOutcome Class: Adjusted rdfs:comment to be accurate (#54).
		Changes relevant to Full Tier
		Counterfactual Class: Made rdfs:comment consistent and converted time:hasTime to start/end time properties (#58).
		HowMuchImpact Class: Made rdfs:comment consistent and replaced time:hasTime with start/end time properties (#57).
		ImpactModel & Subclasses: Made rdfs:comment, rdfs:label, dc:description, and cids:hasName consistent for ImpactModel and its subclasses (#49).
		ImpactRisk Class: Added missing forImpactReport object property and made rdfs:comment consistent (#59).
		Program Class: Fixed rdfs:comment, added hasImpactModel property, and fixed other properties and restrictions (#66).
		Changes relevant above Full Tier
		Activity Class: Added missing hasName property restriction and updated rdfs:comment description (#47).
		Input Class: Added rdfs:comment for Input and its subclasses, and fixed some property restrictions (#67).
		Output Class: Fixed rdfs:comment (#68). Service Class: Replaced time:hasTime with start/end time properties, fixed hasName restriction, and made rdfs:comment consistent (#56).
		Cleanup of cruft remaining in OWL from older versions
		Person Class: Removed unneeded properties hasDisability, hasDisease, hasImmigrationStatus, and hasMaritalStatus, along with their corresponding classes (#74).
		General cleanup: Removed CompositeCharacteristic and PrimitiveCharacteristic classes (#70). Removed DirectionOfChange class (#71). Removed ImpactImportance class (#72). Removed RatioIndicator class, which was redundantly defined from the ISO 21972 ontology (#73). Removed FinancialResource, PhysicalResource, and SkillResource classes; adjusted Input subclasses property restrictions to use act:Resource (#75). Dropped LogicModel class and the hasActivity property on ImpactModel (#49).

How to read this document

The Common Impact Data Standard specifies an ontology for impact measurement. The ontology is currently implemented in Web Ontology Language (OWL). Developers may find the OWL file most useful, while others will find this document a more readable format. Both this document and the OWL file include all the information you need to understand and implement the standard.

This document has three main purposes:

1. It communicates specifications for the Common Impact Data Standard.
2. It contains a detailed description of the standard for software vendors interested in providing impact measurement applications for their clients.
3. It gives software developers a technical introduction to the data standard and orients them in the field of impact measurement.

The goal is to ensure that those in various roles within software development organizations have a shared understanding of the problem the data standard aims to address and the nature of the solution.

All readers Everyone involved in software development should read and understand Section 1: Introduction to the Common Impact Data Standard, which establishes the motivation for the standard. If you are curious about the Common Impact Data Standard but not someone who develops software, we recommend you read our non-technical resources: Introduction to the Common Impact Data Standard and Linking impact data: How a data ontology can ease impact data collection and analysis.

Leadership at software companies If you are in a leadership role at a software company and unlikely to write the code yourself, you may benefit from reading Section 2: Common Impact Data Standard. However, we recommend you skip these formal tables and focus on Class descriptions and diagrams. You will particularly want to focus on Figure 3 (at the beginning of Section 2: Common Impact Data Standard), which shows relationships at a high level and how they demonstrate an organization’s impact.

Software developers If you are a developer, you will need more detail, and you should acquaint yourself with the individual Class tables in Section 2: Common Impact Data Standard. You should also ensure you understand the conceptual mappings in Section 1.2: What is the "impact" that the Common Impact Data Standard represents?, as they will allow you to better understand your users’ requirements. Section 3: Foundational Ontologies provides documentation for external ontologies that describe categories of knowledge, such as time measurement and addresses. If you track this level of detail in your implementation, these classes and properties are available for defining precise relationships that underlie or elaborate upon your Impact Measurement information.

Introduction to the Common Impact Data Standard

The Common Impact Data Standard (Data Standard) is a standardized way to represent a social purpose organization’s impact model (e.g., impact pathway, theory of change, logic model, outcome chain, etc.) and the effects of their work on people and the planet.

The purpose of the Common Impact Data Standard is to create a shared data model with which to capture, export, and import data about impact measurement. The standard is essentially a set of detailed descriptions of how data should be structured to allow interoperability with other aligned software products. This structure will allow data to be moved between applications without additional mapping.

The Data Standard was developed in consultation with experts and other leading standards, such as the Impact Management Project (now housed at Impact Frontiers). It maps to prevailing impact models and enables aligned software platforms and their clients to represent impact in ways aligned with the global consensus on impact measurement. Software that includes the Common Impact Data Standard can be used to capture the description of a social purpose organization’s work using the language and models they use to describe themselves. This is important for situating your work in terms that your potential clients already understand.

The Data Standard uses JSON-LD, a platform-independent and standardized way of representing the data. A JSON-LD file contains all the metadata and relationships between the data objects. It helps combine, compare, and aggregate complex, multidimensional, and interconnected data. Think of it as a whole database in a text file. In order to align, a developer must be able to collect the fields at the aligned tier and import and export using JSON-LD. The software will also need to create a URI for each instance of a class using a URI format recommended by Common Approach.

Ultimately, the Common Impact Data Standard will facilitate flexible, shareable impact data that allows each social purpose organization to design an impact model that is most relevant to it and its stakeholders.

Benefits of the Common Impact Data Standard

The benefits of the Common Impact Data Standard are:

1. Sophisticated analysis: The Data Standard makes it possible for analysts to integrate their data, thereby enabling more types of analysis (e.g. longitudinal and transversal studies) using a variety of methods. This may lead to a better understanding of needs and a better understanding of what works.
2. More autonomy: Donors, investors, and government agencies are increasingly aware that old impact reporting techniques have burdened grantees and investors. The Data Standard provides funders with the standard definitions they need to understand portfolio-level impacts while leaving social purpose organizations the autonomy to measure impact in ways that best fit the social purpose organizations’ own data needs.
3. Less paperwork: The Data Standard allows impact data to be represented in ways that can accommodate the reporting needs of diverse funders.social purpose organizations utilizing a common impact data standard will need to do less custom reporting.
4. Greater visibility: The Data Standard enables the tagging of an organization’s impact content on the internet, making it easier for search engine users to find impact content on the web.
5. More versatility: The Data Standard makes it easier for organizations to benchmark their impact measurement with other measurement standards and understand their impact in the context of those other standards, such as the UN SDG Global Indicator Framework, IRIS+ and Impact Frontiers.
6. Better impact: When data is connected and aggregated, it can produce more opportunities to create change, including wide-reaching change across organizations. The Data Standard allows networks to pool data, see impact, and use the data to improve impact.

What is the “impact” that the Common Impact Data Standard represents?

We understand impact as a change in outcomes for people and the planet.

The Common Impact Data Standard builds on the Impact Management Norms model, which names five dimensions of Impact: what, who, how much, contribution, and risk. To this, the Common Impact Data Standard adds a sixth dimension of how. “How” represents the efforts that a social purpose organization undertakes to achieve certain Outcomes.

The classes and properties in the Common Impact Data Standard align with prominent impact standards and methods. This makes it possible for social purpose organizations to share data amongst themselves, regardless of the variation they use.

To represent the processes by which a social purpose organization delivers Outcomes to its Stakeholders, the Common Impact Data Standard uses the following classes:

• Program Class
• Service Class
• Activity Class
• Input Class
• Output Class
• Outcome Class
• Indicator Class
• IndicatorReport Class

The terms “metric” and “indicator” are used interchangeably throughout the Common Impact Data Standard. To represent the what, who, how much, contribution and risk dimensions of impact, Common Approach uses the Classes shown in Figure 2.

Language and ontologies of the Common Impact Data Standard

OWL

The Common Impact Data Standard is authored in the Web Ontology Language (OWL), which is used to formally define taxonomy and classification networks for publishing on the Semantic Web. That is to say, for a particular area of practice, OWL provides a machine-readable way to describe:

• What things exist.
• How they relate to one another.

By definition, an OWL ontology conforms to Linked Data requirements (Poblet et al., 2019).

The OWL specifications are laid out in Ontology Tables in Section 2 and Section 3.

Common Impact Data Standard and Foundational Ontologies

The Common Impact Data Standard is fully described in Section 2.

Common Approach developed the ontology to facilitate describing impact measurement in the terms used by investors, funders, and social purpose organizations. It is a high-level conceptual frame that reports at the level of the Impact Management Norms.

Some software vendors may already provide or wish to provide a more fine-grained analysis of programs and activities. The Foundation Ontology documentation (provided in Section 3) describes a set of existing standards which have been included to support such features. They are included in this document for completeness and convenience, but the requirements of impact measurement are captured by the Classes in Section 2.

Ontology Prefixes: Note for Developers

Each of the ontologies used in this project is represented with a short form that can be used as a prefix to indicate where the foundational ontology is published. For example, “ic” refers to the International Contacts Ontology, which provides a standard for storing addresses and phone numbers (available at http://ontology.eil.utoronto.ca/icontact.owl). The prefixes are part of the name of the Class. Where no prefix is included, it can be assumed to be a part of the Common Impact Data Standard, although “cids” may also be used if a prefix is included for disambiguation. This means that Activity and act:Activity refer to different Class descriptions and are not interchangeable. However, cids:Activity and Activity are two ways of representing the same Class.

As in object-oriented languages such as Java, the properties of Classes have descent. That is, any Class which is a subClass of another can use any property:value pairs described in the superClass.

For example, LogicModel has access to all the properties contained in ImpactModel, as well as the ones explicitly added in its own class definition. This is also true for Core ontology members that have a superClass from the Foundation ontology (such as the previously-mentioned Activity, which is a subClass of act:Activity.)

Classes

Each class describes a type of thing (e.g. Organization, Activity, Indicator) and includes a list of rules about how to describe it, including where it fits in the conceptual framework.

In this document, each class is described by a table. The tables show formal statements of some combination of:

• How to store values directly (e.g. a string that is used as a name).
• Relationships between objects (i.e. links to other Classes).
• Constraints on what is allowed (e.g. on how many of each type of thing can or must exist).

Even if you are new to OWL, the tables should still be relatively self-explanatory for those with a technical background. The constraints on the values are similar to those you would find in a relational database, and the descriptions of classes look similar to objects in OOP.

The ontology specifies the “classes,” “properties,” and possible restrictions on the “values” of a property within the context of a class. While it utilizes a simplified version of the Manchester syntax (Horridge et al., 2016) for Description Logic, formal definitions of classes are not provided. They can be found in the OWL file at https://ontology.commonapproach.org/cids.ttl.

The following table is an example. The class column specifies the name of the class being defined. This table describes the Organization class—this is a partial list for explanatory purposes and should not be used as a reference. The complete description of the Organization class is below.

The first line states that Organization is a subclass of org:Organization, which is defined in the foundational ontologies (Section 3). The property column specifies the properties used to define the class. Organization has properties including name, legal name, and address. The Value Restriction column specifies the constraints on the values of each property for the class. The value of the “hasName” property must be a string. The value of the “ic:hasAddress” property must be at most one instance of the class ic:Address.

Class	Property	Value Restriction
Organization	rdfs:subClassOf	org:Organization
	hasName	only xsd:string
	sch:legalName	exactly 1 xsd:string
	ic:hasAddress	max 1 ic:Address

Table 1: Partial representation of the class Organization (example only).

The following value restrictions are used in this document:

• “min n”: Specifies that the property has to have a minimum of n values.
• “max n”: Specifies that the property has to have a maximum of n values.
• “exactly n”: Specifies that the property has to have exactly n values.
• “only”: Specifies that the values of the property can only be an instance/type of the class specified, e.g., a string, integer, or another class such as Organization.

We use camelCase for specifying classes, properties and instances. For example, hasName instead of has_name. The first letter of a class name is capitalized. The first letter of a property and instance name are not capitalized. For example, the O in “Organization” is capitalized, but the h” in hasName` is not.

Any instance of a class must satisfy the class’s definition, including conforming to any restrictions on properties and values. Table 2 defines an instance of Organization. acmeSocialServices is of rdfs:type Organization. rdfs:type signifies that it is an instance. The remaining properties provide additional information about acmeSocialServices. Note that if we left out the property sch:legalName, it would be an error as the definition of Organization above has a value restriction for the property sch:legalName of having exactly 1 xsd:string. If zero or more than one sch:legalName was specified, it would be an error. The value of ic:address is NOT a string, but an instance of ic:Address class. In this example, properties have prefixes which identify the complete URI (i.e., namespace or library where the property name originates from).

Instance	Property	Value
acmeSocialServices	rdfs:type	cids:Organization
	hasName	"Acme Social Services"
	sch:legalName	"Ontario 12345 Ltd."
	ic:hasAddress	acmeAddress
acmeAddress	rdfs:type	ic:Address
	ic:hasStreet	"Bloor"
	ic:hasStreetType	ic:street
	ic:hasDirection	ic:west
	ic:hasStreetNumber	0

Table 2: An example of an Instance of an Organization

Identifying Relationships between Things

You will see that the value in a property may be an instance of another class. These relationships form the links in the graph and can be used to describe rich and flexible networks of activities, programs, and impacts across the whole range of an organization’s stakeholders.

Some of the most important connections are illustrated in the accompanying figures—these are not comprehensive but are offered to ease the process of reading the ontology. When examining the figures, you should focus on the highlighted Classes, which are explained in that section. Other relationships are expanded upon in other sections.

You should note that property/value restrictions describe relationships between instances in a graph, not between the Classes themselves.

Software alignment with the Common Impact Data Standard

There are three different tiers of alignment. Software aligned at the Basic Tier can capture, import and export the most simple fundamentals of impact measurement. Software aligned at the Essential Tier can capture all Basic Tier impact data plus the five dimensions of impact as articulated by the Impact Management Norms. Software aligned at the Full Tier can capture all the Essential Tier requirements plus data required for an Impact Pathway and information about the quality of the data. Aligned software must also provide each instance of a class with a URI in a CIDS-recommended format.

Basic Tier	Essential Tier	Full Tier
Organization (hasLegalName, ic:hasAddress, hasOutcome, hasIndicator) Outcome (hasName, hasDescription, forOrganization, forTheme, hasIndicator) Indicator (hasName, hasDescription, forOutcome, forOrganization, i72:unit_of_measure, hasIndicatorReport) IndicatorReport (hasName, i72:value, i72:unit_of_measure, hasComment, prov:startedAtTime, prov:endedAtTime, forIndicator) Theme (hasName, hasDescription, hasCode, relatesTo)	All Basic Tier classes and properties plus: Organization (org:hasID,org:hasLegalStatus,hasCharacteristic) Outcome (hasCode, hasStakeholderOutcome) Indicator (definedBy, forOutcome, hasBaseline, hasTarget, hasCode) IndicatorReport (forTarget) Target (hasName, i72:value, i72:unit_of_measure, prov:startedAtTime, prov:endedAtTime, hasComment) Stakeholder (hasName, hasDescription, hasCatchmentArea, hasCharacteristic, forOrganization) Characteristic (hasName, hasCode, hasValue) StakeholderOutcome (hasName, hasDescription, hasCode, forStakeholder, forOutcome, hasImportance, isUnderserved, hasImpactReport) ImpactReport (forOrganization, prov:startedAtTime, prov:endedAtTime, forOutcome, hasName) ImpactPathway (hasOutcome, hasStakeholderOutcome, hasIndicator, hasIndicatorReport)	All Essential Tier classes and properties plus: Organization (hasProgram, hasContact) Program (all properties) ImpactModel (all properties) Outcome (canProduce, canEnable) Indicator (usesOutput, threshold, generatedBy, dataset) IndicatorReport (all properties) StakeholderOutcome (fromThePerspectiveOf, IntendedImpact) Impact Report (hasReportedImpact, ImpactRisk, ImpactDuration, hasExpectation, Counterfactual)

Common Impact Data Standard

In this section, we define the classes that comprise the Common Impact Data Standard Core Ontology. Figure 3 depicts the main classes and a subset of the properties that connect them. The classes and properties together are sufficient for representing any sort of impact model, be it a logic model, theory of change, outcomes map or impact map. Classes in blue define the impact model, and classes in white report on the performance of the organization’s activities with respect to their impact model. For simplicity, this depiction does not portray all of the relationships between classes.

ImpactModel

ImpactModel definition

We use the term impact model to describe any model that articulates how an organization creates impact. Examples of types of impact models include impact pathway, logic model, logical framework analysis, theory of change, outcome chain, impact map, results framework, results chain and outcomes map. Those familiar with these terms will know these are overlapping concepts. For example an impact map is an impact pathway with the addition of impact valuation. A theory of change is a detailed impact pathway with clearly specified assumptions and internal and external enablers. At Common Approach, we use the term impact model as a general catchall term.

The Common Impact Data Standard is designed to represent the different variations of impact models used by social purpose organizations. Of course, many software vendors only implement one model. That is fine!

The ImpactModel class is the root of a taxonomy of impact models. In this section, we elaborate on two: impact pathway and outcome chain. The properties of each reflect the differences in focus and levels of detail.

Figure 4 depicts the main classes and properties of an Impact Model.

ImpactPathway

ImpactPathway definition

An impact pathway is a “sequence that links organizations’ actions with their effects on people and the natural environment. The impact pathway describes the link between organizations’ inputs, activities and outputs with their effects on people and the natural environment, notably outcomes and impact.” (Impact Management Platform). An impact pathway is at the heart of most impact models.

OutcomeChain

OutcomeChain definition

An outcome chain or outcome hierarchy is a simple impact model that “shows all the outcomes (from short-term to longer-term) required to bring about the ultimate goal of an intervention” (Better Evaluation). On its own, an outcome chain is the simplest impact model. An outcome chain is often combined with an impact pathway and/or theory of change to create a sophisticated impact model.

Code

Code definition

The Common Impact Data Standard is designed to work with other standards. There are many schemas and taxonomies to support impact measurement. To support interoperability between standards, the Common Impact Data Standard uses the Code class.

The Code class is used to reference taxonomies of outcomes, stakeholder characteristics, themes, indicators, etc. Taxonomies can be externally defined, as in the SDGs or IRIS+ Indicators; or they can be internally defined, such as a list of StakeholderCharacteristics.

Organization

Organization

Outcome, StakeholderOutcome, and ImpactReport

Outcome

Outcome definition

An outcome is the level of well-being experienced by a group of people, or the condition of the natural environment, as a result of an event or action (Source: Impact Management Norms). Outcomes are what stakeholders experience as a result of an organization’s activities. They can be positive or negative, intended or unintended.

Impact Management Norms’ Five Dimensions of Impact and Data Categories require a What-Who combination. For example, the outcome level in the period refers to the level experienced by a particular stakeholder group. It is not just the level of the outcome (what) but the level experienced by the stakeholder (who). The measured level refers to a specific what-who combination. Similarly, the importance of an outcome to a stakeholder is not just the importance of the outcome (what) but to a specific stakeholder (who). The class StakeholderOutcome represents this What-Who combination.

• An organization may define several outcomes and several stakeholders. The organization may wish to report how different stakeholder groups (e.g. children, men, women, newcomers) experience the outcome (e.g. food security). StakeholderOutcome creates the who-what combination to represent the level of outcome experienced by a specific stakeholder group.
• To help ensure that organizations are listening to and meeting the needs of stakeholders, Impact Management Norms recommend that organizations know and disclose the importance of the outcome to each stakeholder (e.g., “high importance,” “moderate important,” “neutral,” or “unimportant”), and from whose perspective its importance was assessed (fromPerspectiveOf). This is represented by the StakeholderOutcome hasImporance. When the stakeholder is unable to express importance, the importance may be from the perspective of another entity. For example, the importance of an outcome to the planet may be from the perspective of the Intergovernmental Panel on Climate Change (IPCC). Similarly, the importance to a child might be assessed from the perspective of the parents. FromPerspectiveOf can also be used to indicate when the social purpose organization has estimated the importance of the outcome on behalf of the stakeholder (though this is not ideal).
• Targets, baselines and contributions can be represented for each StakeholderOutcome. Since StakeholderOutcome refers to a specific Stakeholder, a more specific outcome and set of indicators can be defined and used to measure the impact (hasIndicator), and the report of actual impact (hasImpactReport).

Figure 6 depicts the main classes and properties of the Outcome pattern.

Theme

Theme definition

We use the word theme to describe a shared, high-level outcome pursued by many organizations. Examples of themes include taxonomies published for all to use, such as the Sustainable Development Goals (SDGs) and IRIS+ Impact Themes. A theme can also be shared by a smaller group of organizations, such as an impact investors’ portfolio of investees. In this latter case, the impact investor might choose to create its own custom set of themes which it would communicate to its investees. The investees are then able to use the Theme class to communicate to their investor how the investee’s outcomes map to the investor’s themes.

The Theme class is used to represent the impact themes for which outcomes are specified. Outcomes contribute to themes.

StakeholderOutcome

StakeholderOutcome definition

StakeholderOutcome specifies the outcome for a specific stakeholder, as well as properties of that outcome, such as if the stakeholder is underserved with respect to this outcome. StakeholderOutcome is not an alternative to Outcome; rather it is a specialization of a more general Outcome but for a specific stakeholder.

ImpactReport

ImpactReport definition

The ImpactReport represents how much, contribution and risk dimensions for each StakeholderOutcome:

• How much of the outcome is occurring – across scale, depth and duration?
• Would this change likely have happened anyway?

How much measures the degree of impact a social purpose organization has on its stakeholders. The ImpactReport allows indicators in the impact report to be classified according to the how much dimension of impact norms:

• ImpactScale: Refers to indicators that measure the number of individuals who are affected by the social purpose organization’s outcome.
• ImpactDepth: Refers to indicators that measure the degree of change experienced by the stakeholders compared to some baseline determined prior to the service being provided.
• ImpactDuration: Refers to indicators that measure how long the stakeholder experiences, or is likely to experience, the outcome.

Contribution compares the degree of impact against a control group or a baseline. A social purpose organization measuring a counterfactual would use the Counterfactual class to specify the spatial area over which the counterfactual was measured, the time interval, method of measurement and the value of the measurement. All indicators in the ImpactReport can be replicated as counterfactual. Scale, depth and duration indicators can each be replicated for the counterfactual.

The ImpactScale, ImpactDepth and ImpactDuration each includes the properties:

• hasIndicator: Links to the Indicators of outcome used to measure the impact.
• prov:wasGeneratedBy: Links to the activity that generated the impact value if an indicator is not specified.
• hasCounterfactual: Links to a Counterfactual which can be used to calculate what the impact on stakeholders would be if the stakeholders did not receive the service.

The Counterfactual class specifies the spatial area over which the counterfactual was measured, the time interval, the method of measurement and the value of the measurement.

Figure 7 depicts the ImpactReport pattern. There are three core classes: ImpactReport which records the impact the service has on stakeholders; Indicator, which is used to measure the impact; and Counterfactual, which is used to measure stakeholder impact in the absence of the service being provided.

HowMuchImpact

HowMuchImpact definition

HowMuchImpact defines the properties common to ImpactScale, ImpactDepth and ImpactDuration.

Counterfactual

Counterfactual definition

Counterfactual defines what the impact on stakeholders would be if the stakeholders did not receive the service.

Impact Risk

ImpactRisk definition

ImpactRisk “assesses the likelihood that impact will be different than expected and that the difference will be material from the perspective of people or the planet who experience impact.” (Source: Impact Management Norms.)

Stating the riskiness of the impact is important for interpreting the subsequent results. Risk is one of the five dimensions of impact as defined by the Impact Norms.

Stakeholder, Characteristic, StakeHolderReport, and CharacteristicReport

A stakeholder either benefits from the services of an organization or contributes to them. The Stakeholder class identifies what activities they perform using the performs property, and where they are located geographically using the i72:located_in property. Some methods for measuring impact, such as a social return on investment (SROI), require that social purpose organizations distinguish between the beneficial and contributing stakeholders.

• A BeneficialStakeholder is a stakeholder that benefits from a logic model’s outcome.
• A ContributorStakeholder is a stakeholder that contributes input to a service that can produce outcomes.

These are explicitly defined as separate classes because some impact measurement approaches, such as SROI, distinguish between the two.

The following graph (Figure 8) depicts the main classes and properties of a Stakeholder:

Stakeholder

Stakeholder definition

A stakeholder may be an individual person, but is more often a group or category of people, an organization, or a feature. Stakeholders may be described as either contributing or beneficial stakeholders, as suggested by Social Value International.

Beneficial Stakeholders may also be identified by their roles, as specified by the Impact Management Norms: customers, employees, communities, suppliers, and planet.

Contributing Stakeholders contribute Inputs for Programs, Services, or Activities.

Characteristic

Characteristic definition

There are myriad characteristics that social purpose organizations might use to identify a beneficial stakeholder. There are characteristics that the stakeholder must have (i.e., requirements) to be eligible for their services. There are also characteristics that the organization might track to learn more about which people are accessing their services. Common stakeholder characteristics are gender, age, ethnicity, income, geographic location, and disability.

The specification of stakeholder characteristics is often theme-dependent. For example, social purpose organizations working to end homelessness often define stakeholders by characteristics such as length of time, frequency of homelessness, and location of homelessness (e.g., street, shelter, friend’s home). These characteristics are used to determine which services are relevant. Social purpose organizations are often asked to track specific characteristics for different funders and partnerships.

Listing a set of properties, the approach taken by vocabularies such as FOAF and Schema.org, is insufficient for the Common Impact Data Standard for a number of reasons:

• The possible set of properties associated with a Stakeholder is enormous when taking the union across themes and sources, leading to an overloading of the concept.
• The plethora of properties across themes leads to ambiguous and overlapping interpretations.
• The temporal aspect of a property is ignored, i.e., over what period of time is the property valid? (See Katsumi & Fox (2019) for one possible approach to dealing with this.)
• The causal aspect of a property is ignored, i.e., what led to the person having the property.

The Characteristic class is used to define a characteristic of a Stakeholder. It has a hasCode property, enabling the reuse of defined characteristic taxonomies.

StakeholderReport

StakeholderReport definition

Stakeholder data evolves over time. The StakeholderReport class is used to identify the number of stakeholders who possess certain characteristics over a period of time.

CharacteristicReport

CharacteristicReport definition

The CharacteristicReport class identifies the number of members which possess a certain characteristic or set of characteristics over a period of time.

Indicator, IndicatorReport and Target

The terms “metric” and “indicator” are used interchangeably in the data standard. In this section, we define the Indicator, IndicatorReport, and Target classes.

Indicator

Indicator definition

Indicator is a subclass of i72:Indicator (see Address - TOVE/icontact), which provides properties for units of measure, time and value.

IndicatorReport

IndicatorReport definition

IndicatorReport is used to report the value of an indicator for some time interval. In addition to the value of the indicator, it reports on when it was generated, the activity used to generate it, the datasets used, and the quality of the value reported using the DQV vocabulary (https://www.w3.org/TR/vocab-dqv/).

Target

Target definition

The target is used to report the target value of an indicator and/or indicator report for some time interval. In addition to the target value and time interval of the target, this class also reports the units of measure of the target, the date the target was created, the name of the target, and any comment about the target that the user may wish to add.

Program

Program definition

A program defines a set of services that focus on a shared set of outcomes. For example, a “poverty reduction program” can be made up of services such as mobile services that provide food and clothing to those experiencing homelessness and a training service that provides basic skills for those experiencing homelessness. The Program class has a set of Stakeholders who may contribute or benefit.

Service

Service definition

A program is composed of one or more services. As described above, a poverty reduction program can have many services, with each service comprised of different activities, inputs, outputs, and outcomes. Service is a subclass of Activity and can be related to one or more Programs.

Activity

Activity definition

Activity defines the actions performed by an organization and/or contributing stakeholder to implement a service. The Common Impact Data Standard’s Activity class is defined to be a subclass of the TOVE Activity ontology, and is extended by including properties for Input, Output, and what Service or Activity it is a subActivityOf. An activity’s type is based on its outcome rather than service or input. This allows activities to be classified by the type of change they produce rather than by what resources they use (input) or who performs the activity (service).

Input

Input definition

A key component of impact models is inputs. Inputs specify the resources required by a social purpose organization to produce results (Ralser, 2008). An input is provided by a contributing stakeholder and may come in many forms. We identify three broad categories of the Input class:

• FinancialInput: Represents a monetary resource, with a monetary unit of measure, such as donating cash or paying off debt.
• SkillInput: Any type of skills-based expertise such as legal, translation, carpentry, etc.
• PhysicalInput: Any type of physical item, such as food, clothing, furniture, etc.

Output

Output definition

An output is “the direct result of an entity’s activities (e.g. wages paid, hours of training provided, products and services sold). It may also include changes resulting from the entity’s actions or decisions which are relevant to achieving outcomes.” (Source: UN SDG Impact Standards Glossary).

Outputs represent a quantitative summary of an activity. For example, if the activity is “we provide training,” the output is “we trained 50 people to NVQ level 3.” (Source: Social Value International, 2012.) An example of a production output would be “we produce 100 meals for people experiencing homelessness”. An output represents what has been produced and the quantity.

Note: Many impact models illustrate outputs leading to outcomes. Outputs describe the quantity of activity.

Foundational Ontologies

The Foundation Ontologies are a set of preexisting ontologies used by the Common Impact Data Standard. They provide basic representations of time, address, phone number, measurement, indicator, person, and activity.

Date and Time in the Common Impact Standard

Introduction

Time is both absolute and relative. To understand impact data, it is often necessary to know at what time something occurred and whether something occurred before, after or during some other event. It is not enough to record a date. An impact ontology requires a much richer representation of time that supports reasoning about time points, time intervals, and the relationships among them. In summary, the ontology needs to be able to support the answering of questions such as:

• At what time did some activity or measurement occur?
• What was the duration of the activity?
• Did the activity occur before, after or during some other activity?

Many time ontologies have been developed as well as time and date schemas. This document reuses the “Time Ontology in OWL: W3C Candidate Recommendation 26 March 2020” (https://www.w3.org/TR/owl-time/), the W3C XSD time schema (https://www.w3.org/TR/xmlschema-2/) and specific properties from the “PROV-O: The PROV Ontology W3C Recommendation 30 April 2013” (https://www.w3.org/TR/prov-o/) to record the beginning and ending of time periods. To reduce the ambiguity of recording and parsing time, the specific XSD datetime data type is the extended format “YYYY-MM-DDThh:mm:ss[Z| (+|-)hh:mm]” which records timezone while being ISO8601 compliant.

Core Classes and Properties

Several classes are time intervals having a beginning time instant and an ending time instant. We reused the PROV-O properties for prov:startedAtTime and prov:endedAtTime to identify the start and end of time intervals. “Start” is when an activity is deemed to have been started by an entity, known as trigger. The activity did not exist before its start. Any usage, generation, or invalidation involving an activity follows the activity's start. A start may refer to a trigger entity that set off the activity, or to an activity, known as starter, that generated the trigger.

End is when an activity is deemed to have been ended by an entity, known as trigger. The activity no longer exists after its end. Any usage, generation, or invalidation involving an activity precedes the activity's end. An end may refer to a trigger entity that terminated the activity, or to an activity, known as ender that generated the trigger. The values of prov:startedAtTime and prov:endedAtTime should conform to the ISO8601 compliant form of the XSD Time Date schema “YYYY-MM-DDThh:mm:ss[Z| (+|-)hh:mm]”.

Classes which are time intervals are also subclasses of the OWL-Time time:TemporalEntity class. This enables the use of W3C Time ontology properties for applications that require temporal definitions that are too complex or abstract for simple prov:startedAtTime and prov:endedAtTime properties. Examples include financial quarters, non-gregorian calendar dates and abstract calendar definitions, such as the first business day of the year 2026.

Fundamental to any conceptual model, including an impact model, is the time at which things occur. For example, questions may arise regarding the temporal relationship among measurements. Not just at what time something was measured but whether it was measured before, after or during some event. The use of the Time Ontology also permits the recording of “common sense” relationships between activities irrespective of whether simple start/end properties or complex time descriptiosn are used.

Activities that follow each other temporally can be recorded using the time:before and time:after properties, which record both the logical and temporal sequence of Activities. This enables the consumers of the data to follow the logical progression of a program to its end without having to compare all activity timestamps. Another Time Ontology property time:intervalIn enables the convenient recording of subordinate activities (from a temporal perspective) without incurring the cost of searching all Activity time and date stamps.

Address – TOVE/icontact

Introduction

Addresses worldwide vary in the types of information they include. For example, a British or Indian address may refer to a building name and a section of a city. This document reuses the International Contact Ontology, which is equipped to represent most global addresses. The International Contact Ontology can be accessed at http://ontology.eil.utoronto.ca/tove/icontact.owl.

Formal Specification

The concept of the Address class deconstructs the address into its constituents.

Class	Property	Value Restriction
ic:Address	ic:hasAddressType	only ic:AddressType
	ic:hasStreetNumber	max 1 xsd:nonNegativeInteger
	ic:hasStreet	max 1 xsd:string
	ic:hasStreetType	max 1 ic:StreetType
	ic:hasStreetDirection	max 1 ic:StreetDirection
	ic:hasUnitNumber	max 1 xsd:nonNegativeInteger
	ic:hasPostalBox	max 1 xsd:string
	ic:hasBuilding	max 1 xsd:string
	ic:hasCitySection	max 1 xsd:string
	ic:hasCity	max 1 sch:City
	ic:hasState	max 1 sch:State
	ic:hasPostalCode	max 1 xsd:string
	ic:hasCountry (ISO 3166-2 alpha-2 2 letter country code)	max 1 sch:Country
	wgs84:lat	max 1 xsd:decimal
	wgs84:long	max 1 xsd:decimal
ic:AddressType	owl:equivalentTo	{ic:main, ic:division, ic:regional, ic:branch}
ic:StreetDirection	owl:equivalentTo	{ic:east, ic:north, ic:south, ic:west}
ic:StreetType	owl:equivalentTo	{ic:avenue, ic:boulevard, ic:circle, ic:crescent, ic:drive, ic:road, ic:street}

Phone Number – tove/icontact

The PhoneNumber class decomposes a phone number into its individual parts. Properties in blue are inherited from the superclass ic:PhoneNumber. This document reuses the International Contact Ontology.

Class	Property	Value Restriction
ic:PhoneNumber	ic:hasCountryCode	exactly 1 xsd:nonNegativeInteger
	ic:hasAreaCode	exactly 1 xsd:nonNegativeInteger
	ic:hasPhoneNumber	exactly 1 xsd:nonNegativeInteger
	ic:hasPhoneType	exactly 1 PhoneType
ic:PhoneType	owl:equivalentTo	{ic:mainline, ic:faxPhone, ic:cellPhone}

Measurement – ISO/IEC 21972:2020

Implementation of i72:unit_of_measure

The property i72:unit_of_measure should have the value range of exactly 1 xsd:string.

Introduction

The purpose of a measurement ontology is to provide the underlying semantics of a number, such as what is being measured and the unit of measurement. A measurement ontology makes it possible to ensure that numbers, such as those used in indicator reports, are of the same type. For example, to clarify if “5” is a count or a percentage; or to ensure that when two numbers are used in a ratio, they are expressed in the same scale. Consider an advocacy group that is working to end homelessness. They use data from two different sources to track the percentage of the homeless that are male. To do this, they need to know that the data of homeless men and total homeless are of the same scale (for example: hundreds versus thousands).

This document reuses “ISO/IEC 21972:2020 Information technology — Upper-level ontology for smart city indicators” (accessible at https://www.iso.org/standard/72325.html), which provides a representation for the definition of indicators.

Core Classes and Properties

The Common Impact Data Standard representation of measurement concepts reuses ISO 21972, which is based on the OM measurement ontology (Rijgersberg et al., 2013). The top row of Figure 12 depicts the basic classes of the measurement ontology. There are three main classes:

• Quantity: Denotes what is being measured (e.g., the diameter of a ball) and links to the actual thing being measured via the phenomenon property, and the amount of the quantity via the value property that links to a Measure.
• Unit_of_measure: “Is a definite magnitude of a quantity, defined and adopted by convention and/or by law. It is used as a standard for measurement of the same quantity, where any other value of the quantity can be expressed as a simple multiple of the unit of measure. For example, length is a quantity; the metre is a unit of length that represents a definite predetermined length. When we say 10 metre (or 10 m), we actually mean 10 times the definite predetermined length called ‘metre’.” (Rijgersberg et al., 2013).
• Measure: Denotes the value of the measurement (via the numerical_value property), which is linked to both Quantity and Unit_of_measure.

For example, Male Homeless Ratio is a subclass of Quantity that has a value that is a subclass of Measure whose units are a ‘population ratio unit’ that is an instance of Unit_of_measure. The actual value measured is a property of the Measure subclass “Male homeless ratio measure.”

The concept of a quantity is common across many standards. International Bureau of Weights and Measures defines in JCGM 200:2012 that a quantity is a “property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference”. W3C defines a quantity as “a (scalar) physical quantity or dimensionless number”. QUDT defines a quantity to be “the measurement of an observable property of a particular object, event, or physical system.” The definition of quantity adopted in this document is the OM version defined above.

Unit_of_measure is divided into three subclasses as outlined below and illustrated in Figure 13:

• Singular_unit: E.g.a metre.
• Unit_multiple_or_submultiple: Defines multiples or submultiples of a Singular_unit. For example, if the singular unit is a metre, then a kilometre would be a multiple, and a centimetre would be a submultiple. There are other possible multiples and submultiples. A Unit_multiple_or_submultiple links to the singular unit it is a multiple of via the singular_unit property.
• Compound_unit: Denotes a combination of more than one Unit_of_measure. For example, speed would be an instance of a Unit_division where a singular (e.g., metre) or multiple unit (e.g., kilometer) would be divided by time (e.g., hour).

Defining a unit of measure not only requires the specification of whether it is singular or compound, but whether the scale of the unit is nominal, ordinal, interval or ratio. The latter two scales are also called cardinal scales. An example of a scale is the Celsius scale, a temperature scale. For ratio scales[^1], a zero point can be defined. The measurement scale taxonomy is illustrated in Figure 14.

Formal Specification

The following tables formally define each of the classes of the measurement portion of this document.

Class	Property	Value Restriction
i72:Quantity	i72:value	exactly 1 i72:Measure
	i72:unit_of_measure	exactly 1 i72:Unit_of_measure
	i72:phenomenon	exactly 1 owl:Thing
i72:Measure	i72:unit_of_measure	exactly 1 i72:Unit_of_measure
	i72:numerical_value	exactly 1 xsd:string
i72:Unit_of_measure	rdfs::subClassOf	owl:Thing
i72:Singular_unit	rdfs:subClassOf	i72:Unit_of_measure
i72:Unit_multiple_or_submultiple	rdfs:subClassOf	i72:Unit_of_measure
	i72:prefix	exactly 1 i72:Prefix
	i72:singular_unit	exactly 1 i72:Singular_unit
	i72:symbol	min 1 xsd:String
i72:Compound_unit	rdfs:subClassOf	i72:Unit_of_measure
i72:Unit_multiplication	rdfs:subClassOf	i72:Compound_unit
	i72:term_1	exatly 1 i72:Unit_of_measure
	i72:term_2	exactly 1 i72:Unit_of_measure
i72:Unit_division	rdfs:subClassOf	i72:Compound_unit
	i72:numerator	exactly 1 i72:Unit_of_measure
	i72:denominator	exactly 1 i72:Unit_of_measure
i72:Measurement_scale	rdfs:subClassOf	rdfs:Class
i72:Nominal_scale	rdfs:subClassOf	i72:Measurement_scale
i72:Ordinal_scale	rdfs:subClassOf	i72:Measurement_scale
i72:Cardinal_scale	rdfs:subClassOf	i72:Measurement_scale
i72:Interval_scale	rdfs:subClassOf	i72:Cardinal_scale
i72:Ratio_scale	rdfs:subClassOf	i72:Cardinal_scale
	i72:zero_element	exactly 1 i72:Fixed_zero_point
i72:Fixed_zero_point	rdfs:subClassOf	i72:Fixed_point
	numerical_value	i72:value “0”
i72:Fixed_point	rdfs:subClassOf	i72:Point
i72:Point	rdfs:comment	“A point is an element of an interval scale or a ratio scale, for example, 273.16 on the Kelvin scale indicates the triple point of water thermodynamic temperature. (OM, 2011)”.

Indicator – ISO/IEC 21972:2020

Introduction

Indicators are used to measure the outcomes of social purpose organizations. A challenge for social purpose organizations is to define Indicators in ways that are precise, objective and verifiable. Sadly, English is too imprecise a language for defining indicators such that they are consistently applied across social purpose organizations. Consequently, the preferred approach is to formally represent the indicator definition using ontologies. If a definition changes, then the definition of the indicator is modified. If new indicators are introduced, then the definitions of the new indicators are constructed using the ontology. Using the ontology allows each social purpose organization to define its own indicators while providing the analyst (human or machine) the ability to see the differences between the indicators. In this section, we present the core concepts for defining indicators.

This document reuses “ISO/IEC 21972:2020 Information technology—Upper-level ontology for smart city indicators,” accessible at https://www.iso.org/standard/72325.html.

Core Classes and Properties

The Common Impact Data Standard representation of indicator measurement concepts reuses ISO 21972, which is based on the Global City Indicator Foundation Ontology (Fox, 2013; 2105). An indicator is a quantity that is often a ratio of a numerator and denominator that are also quantities. It has a time period associated with it. The numerator and denominator quantities can have different units of measure. One example of a unit of measure is the size of a population. A population_cardinality_unit is a unit of measure of the size of a population. It is defined to be an individual of a Cardinality_unit that is a subclass of a Singular_unit. Figure 15 depicts the specification of the Cardinality_unit.

In Figure 16, population_cardinality_unit is depicted to be an instance of Cardinality_unit, which is the unit of measure for the cardinality of a set defined by a Population (defined in the next clause). It is associated with the symbol “pc”. For example, 1100pc represents a population cardinality (or size) of 1100. This document takes advantage of prefix notations to scale the numbers by defining units of measures: kilopc, megapc and gigapc which are multiples of population_cardinality_unit. 1.1 kilopc represents 1100 pc.

With the above defined, it is possible to introduce the unit of measure for measuring a population ratio. population_ratio_unit is defined to be an instance of Unit_division (see Figure 16 above). It has two properties:

• numerator, whose range is restricted to being a population_cardinality_unit;
• denominator, whose range is restricted to being a population_cardinality_unit.

In other words, a population ratio is the ratio of two population cardinalities (i.e., number of members/elements in each population).

Figure 17 provides the unit of measure for populations (pc) and population ratios (pc/pc).

Formal Specification

In addition to the classes and properties identified in Section 2.4, the following table specifies the key concepts for representing indicator definitions (using the Manchester syntax for Description Logic Full).

Class	Property	Value Restriction
i72:Indicator	rdfs:subClassOf	i72:Quantity
	i72:unit_of_measure	exactly 1 i72:Unit_of_measure
	i72:value	exactly 1 i72:Measure
	i72:for_time_interval	exactly 1 time:DateTImeInterval
i72:RatioIndicator	rdfs:subClassOf	i72:Indicator
	i72:unit_of_measure	exactly 1 i72:Unit_division
	i72:numerator	exactly 1 i72:Quantity
	I72:denominator	exactly 1 i72:Quantity

The basic definitions for population cardinality are as follows:

Class	Property	Value Restriction
i72:Cardinality_unit	rdfs:subClassOf	i72:Singular_unit
	inverse i72:unit_of_measure	exactly 1 i72:Cardinality_scale
i72:Cardinality_scale	rdfs:subClassOf	i72:Ratio_scale
	i72:zero_element	value fixed_zero_cardinality
Individual	Property	Value
i72:fixed_zero_cardinality	rdfs:type	i72:Fixed_zero_point
	i72:numerical_value	0
i72:population_cardinality_unit	rdfs:type	Cardinality_unit
	i72:symbol	“pc”

With the definition of a population_cardinality_unit, the different types of singular units of measures and the compound units of measures upon which they are based on, are defined. Note that the names of individuals of Monetary_unit adopt the ISO 4217 codes for currencies. Any new individuals of Monetary_unit should conform to the ISO 4217 standard. For Unit_multiple_or_submultiple individuals, we adopt ISO 80000 prefixes.

Figure 18 depicts the translation of the Indicator “Average number of skills each job seeker gained”, the indicator ontology, which is based on ISO 21972.

Person

The Person ontology pattern defines human stakeholders and the various relationships they form. Depending on the available data and application needs, the ontology can capture a great deal of detail about an individual. Meeting data privacy requirements is assumed to be the responsibility of the software company using the data ontology.

This document reuses and extends the “CWRC Ontology Specification” because it has already defined many objects that are relevant to Common Approach. CWRC Ontology Specification is accessible at http://sparql.cwrc.ca/ontology/cwrc.html.

Core Concepts and Properties

A person can play a role in an organization. For any role, a person can be assigned an ID, with additional meta-data about the role they play.

Formal Specification

Class	Property	Value Restriction
Person	rdfs:subClassOf	sch:Person
	ic:hasAddress	only ic:Address
	ic:hasPhoneNumber	only ic:PhoneNumber
	ic:hasEmail	only xsd:string
	sc:birthDate	max 1 xsd:dateTime
	foaf:givenName	max 1 xsd:string
	foaf:middleName	max 1 xsd:string
	foaf:familyName	max 1 xsd:string
	sch:indentifier	only xsd:string

Activity – tove/activity

Introduction

In order to represent an organization’s impact model, it is often necessary to represent the activities that the organization undertakes to affect change.

This document reuses and extends the “TOVE Activity ontology” (Fox et al., 1993). TOVE Activity ontology is accessible at http://ontology.eil.utoronto.ca/tove/activity.owl.

Classes and Properties

Action is represented by the combination of an activity and its corresponding enabling and caused states (Figure 19). An activity is the basic transformational action primitive with which processes and operations can be represented. An enabling state defines what has to be true of the world in order for the activity to be performed. A caused state defines what will be true of the world once the activity has been completed.

The status of an activity is reflected in an attribute called status. We define the theme of an activity’s status as a set of linguistic constants.

• dormant: The activity is idle and has never been executed before.
• enabled: The activity is executing.
• suspended: The activity was executing and has been forced to an idle state.
• reEnabled: The activity is executing again.
• completed: The activity has finished.

An activity, along with its enabling and caused states, is called an activity cluster. The state tree linked to an activity by the act:enables relation specifies what has to be true in order for the activity to be performed. The state tree linked to an activity by the act:causes relation defines what will be true of the world once the activity has been completed.

There are two types of states: terminal and non-terminal.

Terminal States:

• Use: Signifies that a resource is to be used, but not consumed, by the activity and will be released once the activity is completed.
• Consume: Signifies that a resource is to be consumed by the activity and will not exist once the activity is completed.
• Release: Signifies that a resource, which has been designated as being used, is now available for use/consumption elsewhere.
• Produce: Signifies that a resource, that did not exist prior to the performance of the activity, has been created by the activity.
• Predicate: Specifies that all substates / at least one substate must be satisfied.

Non-terminal states: allows for the boolean combination of state).

• ConjunctiveState/DisjunctiveState: Specifies that all substates / at least one substate must be satisfied.
• Exclusive: Specifies that only one substate must be satisfied.
• Not: Specifies that the substate must not be satisfied.
• Composite Produce: Signifies that a resource, that did not exist prior to the performance of the activity, has been created by the activity. This resource includes other materials that are only being used for a limited time and will be released by another activity. Except for the composite produce, each of these states can be further classified as being discrete or continuous.

Status: The status of a state is reflected in an attribute called status. We define the theme of a state’s status as a set of linguistic constants. For example, the theme for discrete_consumption is:

• possible/not_possible: A unit of the resource that the state consumes is available/not available at the time required.
• committed: A unit of the resource that the state consumes has been reserved for consumption.
• enabled: A unit of the resource that the state consumes is being consumed.
• completed: A unit of the resource that the state consumes has been consumed and is no longer needed.

We extend it by including properties for Outcome, Output and Input.

Formal Specification

Class	Property	Value Restriction
act:Activity	act:causes	max 1 act:State
	act:enabledBy	max 1 act:State
	act:hasElaboration	only act:Activity
	act:hasStatus	exactly 1 ActivityStatus
	act:initialActivity	max 1 act:Activity
	act:nextActivity	only act:Activity
	act:finalActivity	max 1 act:Activity
act:ActivityStatus	rdfs:subClassOf	act:Status
	owl:equivalentTo	{ act:completed, act:dormant, act:executing, act:reExecuting, act:suspended}
act:State	act:enables	only act:Activity
	act:causedBy	only act:Activity
	act:achievedAt	only time:TemporalEntity
act:TerminalState	rdfs:subClassOf	act:State
	owl:disjointWith	act:NonTerminalState
	act:hasResource	only act:Resource
act:NonTerminalState	rdfs:subClassOf	act:State
	owl:disjointWith	act:TerminalState
	act:hasSubState	only act:State and min 1 act:State
act:ConjunctiveState	rdfs:subClassOf	act:NonTerminalState
	owl:disjointWith	act:DisjunctiveState
act:DisjunctiveState	rdfs:subClassOf	act:NonTerminalState
	owl:disjointWith	act:ConjunctiveState
act:Consume	rdfs:subClassOf	act:TerminalState
act:Produce	rdfs:subClassOf	act:TerminalState
act:Release	rdfs:subClassOf	act:TerminalState
act:Resource	rdfs:subClassOf	owl:Thing

Location

The ontology for representing location information shall conform to the vocabulary specified in OGC 11-052r4 (GeoSPARQL). Capturing generic spatial features requires concepts of location, but also concepts of geometry in order to describe shapes that are more complex than a single point in space. In addition, there is a need to be able to describe the spatial relationship between various features (e.g. containment, overlap). The GeoSPARQL Ontology is used in the Location Pattern to achieve this. It is included in its entirety with the prefix “geo.”.

Classes and properties

The key classes and properties are formalized in Table 3 and Table 4, respectively. In this subclause, a subset of the GeoSPARQL ontology is replicated and specialized:

• Feature: Represents some area in space. Features are distinguished by their geometric shape as well as their geographic location. Core properties are:
  • hasGeometry: Specifies the shape that defines the location of the Feature in order to capture quantitative spatial information.
• Geometry: Represents a shape. Various types (subclasses) of Geometry are defined in the GeoSPARQL ontology including the classes: Point, Polygon, and Curve. Core properties are:
  • asWKT: Specifies the well-known text encoding of a given geometry. The default reference system for the coordinate values is assumed to be WGS84. GeoSPARQL supports the identification of alternate reference systems, captured as IRIs and concatenated with the coordinates.

In addition, the pattern specifies the following generic properties to support the reference of locations by other classes:

• hasLocation: Captures the relationship between objects and the spatial locations they occupy.
• associatedLocation: Introduced to capture the association of a given object with a particular location. For example, a train station can occupy a fairly large spatial location but be associated with a particular point.

Formalization

Class	Property	Value restriction
Feature	rdfs:subClassOf	geo:Feature
	hasGeometry	exactly 1 geo:Geometry
Geometry	rdfs:subClassOf	geo:Geometry
	asWKT	exactly 1 geo:wktLiteral

[^1]: “Ratio data on the ratio scale has measurable intervals. For example, the difference between a height of six feet and five feet is the same as the interval between two feet and three feet. Where the ratio scale differs from the interval scale is that it also has a meaningful zero. The zero in a ratio scale means that something doesn’t exist. For example, the zero in the Kelvin temperature scale means that heat does not exist at zero” (Source: http://www.statisticshowto.com/ratio-scale/).

Cross-reference for Common Impact Data Standard classes, object properties and data properties back to ToC

This section provides details for each class and property defined by Common Impact Data Standard.

References

Fox, M., Chionglo, J.F., and Fadel, F.G., (1993), “A Common Sense Model of the Enterprise”, Proceedings of the 2nd Industrial Engineering Research Conference , pp. 425-429, Norcross GA: Institute for Industrial Engineers.

Fox, M.S., Barbuceanu, M., Gruninger, M., and Lin, J., (1998), “An Organisation Ontology for Enterprise Modeling”, In Simulating Organizations: Computational Models of Institutions and Groups, M. Prietula, K. Carley & L. Gasser (Eds), Menlo Park CA: AAAI/MIT Press, pp. 131-152.

Fox, M.S., (2013), “A Foundation Ontology for Global City Indicators”, Working Paper, Enterprise Integration Laboratory, University of Toronto, Revised 13 October 2017.

Fox, M.S. (2015) “The Role of Ontologies in Publishing and Analyzing City Indicators”, Computers, Environment and Urban Systems, Vol. 54, pp. 266-279.

Horridge, M., Drummond, N., Goodwin, J., Rector, A. L., Stevens, R., & Wang, H. (2006, November). The Manchester OWL syntax. In OWLed (Vol. 216).

Poblet, M., Casanovas, P., & Rodríguez-Doncel, V. (2019). Introduction to Linked Data. In Linked Democracy (pp. 1-25). Springer, Cham. https://link.springer.com/chapter/10.1007/978-3-030-13363-4\_1

Rijgersberg, H., Wigham, M., and Top, J.L., (2011), “How Semantics can Improve Engineering Processes: A Case of Units of Measure and Quantities”, Advanced Engineering Informatics, Vol. 25, pp. 276-287.

Ralser, T., (2008). Organizational Value/Nonprofit ROI. ROI For Nonprofits: The New Key to Sustainability (pp. 51–66). Hoboken, New Jersey: Wiley.