This document provides an overview of the structure of the specification and defines the model of the hierarchical taxonomy that provides the holistic framework for measuring everyday living events. The content of the model is defined in the document by a link to the JSON object.

Status:

This document was last revised or approved by the OASIS Classification of Everyday Living (COEL) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=coel#technical.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment button on the TC’s web page at https://www.oasis-open.org/committees/coel/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/coel/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[COEL-COEL-v1.0]

Classification of Everyday Living Version 1.0. Edited by Joss Langford. 03 December 2015. OASIS Committee Specification Draft 01. http://docs.oasis-open.org/coel/COEL/v1.0/csd01/COEL-v1.0-csd01.html. Latest version: http://docs.oasis-open.org/coel/COEL/v1.0/COEL-v1.0.html.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

1 Introduction. 5

1.1 Terminology. 5

1.2 Normative References. 5

1.3 Non-Normative References. 5

2 Overview of specification. 6

2.1 Knowledge Base. 6

2.2 Data Model 6

2.3 Methodology. 6

3 Structure of the model 8

3.1 Principles behind structuring and populating the knowledge base. 8

3.2 Structure of the model 8

3.2.1 Artifact Format 9

4 Description of taxonomy. 11

4.1 Visualising the model 12

5 Conformance. 13

Appendix A. Acknowledgments. 14

Appendix B. Revision History. 15

1 Introduction

1.1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.2 Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.

[RFC4627] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), July 2006, http://www.ietf.org/rfc/rfc4627.txt.

1.3 Non-Normative References

[Coelition] http://www.coelition.org

[Data to Life] Reed, M. & Langford, J. (2013). Data to Life. Coelition, London. ISBN 978-0957609402

2 Overview of specification

The Classification of Everyday Living (COEL) is a hierarchical taxonomy of everyday human life events. It comprises three distinct aspects: Knowledge Base, Data Model and Methodology. Together these facilitate the creation of personal digital services in a wide range of jurisdictions. For further background on COEL see [Data to Life].

2.1 Knowledge Base

A taxonomy is a highly structured form of knowledge base that links two distinct features: a nomenclature (a way of naming things) and a classification (a way to discriminate between different types of thing based on their features or attributes). Although called the Classification of Everyday Living, COEL is more accurately described as a taxonomy.

The COEL is highly compacted by design, nevertheless, it’s high level structure and content represents a significant knowledge base. The COEL is a taxonomy of human life events, where an event is defined as: ‘a transient and time-bound activity that can be objectively recorded by a person or a device’. Each such life event is called a Behavioral Atom.

The COEL has the ambition of becoming a globally used asset base – a comprehensive and unambiguous taxonomy of human life events.

2.2 Data Model

Although the COEL knowledge base could be structured in many different ways, for ease of human understanding and machine readability the COEL is constructed as a four level hierarchical Data Model. The Behaviourial Atoms in the lower levels are sub-types of a Behaviourial Atom at the next higher level. Thus the lower levels represent progressively more detailed views of life events.

2.3 Methodology

To operationalize the COEL Data Model a methodology is needed to capture, record and communicate data. This methodology is described in the specifications described below.

The complete COEL specification can be read from the top down using the table below as a guide. This set of specifications is the minimum requirement to stand up and use a fully functioning COEL compliant system.

NAME of COEL-TC document	Description
COEL [Classification of Everyday Living]	This document. A high level overview of what COEL is, the design principles by which it was constructed and key references. Permanent links to the detailed content of the latest version of the COEL Data Model.
RPE [Roles, Principles & Ecosystem]	A top level description of the possible structures and operations of a COEL compliant ecosystem. The roles that various actors in the ecosystem play, the principles by which the ecosystem works together, the interaction structure between different actors, the REQUIRED and OPTIONAL data flows within the ecosystem and high level security considerations.
IDA [Identity Authority]	A description of the role and operation of the Identity Authority used to create and manage COEL compliant Pseudonymous Keys.
BAP [Behavioural Atom Protocol]	The means by which COEL event data can be packaged and communicated.
PQI [Public Query Interface]	The minimal requirements of a query interface.
MMI [Minimal Management Interface]	The minimal management interface requirements for operation of the COEL ecosystem.

The specifications are dependent on each other as can be seen in the visualization below.

3 Structure of the model

3.1 Principles behind structuring and populating the knowledge base

The COEL is a new event-based taxonomy for classifying and naming small observable events that form our everyday lives. It was constructed according to a set of design principles, as follows:

· Beneath the important surface of cultural differences, everyday human behavior is surprisingly similar. Our daily lives are made up of a finite number of behaviours which have a natural granularity. A coherent classification of daily events SHOULD work at this level of granularity.

· We SHOULD aim to classify, name and code all of the daily behaviours that make up an individual’s life.

· To provide a robust and accurate view on daily life, we SHOULD only measure and record human behaviours that are observable. Personal emotions / thoughts become observable events when an individual reports those emotions / thoughts, for example in conversation or a digital diary.

· Individual behavioural events SHOULD sit at the bottom of a logically clustered hierarchy. Events that have certain similarities SHOULD be kept together.

· Category errors SHOULD be avoided. The COEL SHOUD only include elements of a single category: events, where an event is defined as: “a transient, time-bound activity that can be objectively recorded by a person or device”.

· Each element in the COEL SHOULD be clearly distinct from all other elements, that is, they SHOULD be Mutually Exclusive.

· In totality, the complete listing of elements in the COEL SHOULD completely cover the whole of everyday human activity, that is, they SHOULD be Completely Exhaustive.

The requirement for the COEL to be both Mutually Exclusive AND Completely Exhaustive (MECE) is particularly demanding. This principle SHOULD be applied to the Class, Sub-class and Element layers of the knowledge base.

The principles above have been used to create the COEL. Future developments and versions of the COEL can be expanded both in depth (by adding more detail at the Element level) and breadth (by adding more Clusters and Classes).

3.2 Structure of the model

The most logical way to describe the structure of the full COEL taxonomy is from the top down. However, the fine-grained (and often most interesting) detail is at the bottom of the hierarchy, at the level of the individual elements.

At the top level of the COEL tree there are about thirty Clusters of event categories that go together. The name of each Cluster has been chosen to be intuitive for users of the classification. Some of these Clusters inevitably have a much richer structure than others, since certain aspects of daily life contain more variation than others.

Below the level of the Clusters come three further levels: Class, Sub-class and Element. This structure is shown schematically below.

The principles in section 3.1 above have been used to create the COEL.

The COEL exists concretely as four digital artefacts – JSON format object definitions for the COEL Clusters, COEL Classes, COEL Sub-classes and COEL Elements. These artefacts are held at the permanent OASIS hosted URIs described above.

Applications that refer to or use the Classification of Everyday Living (COEL) as a coherent Knowledge Base of daily human events or as a Data Model that embodies that knowledge base MUST refer to this document, its subsidiary documents and the four JSON artefacts described above.

3.2.1 Artifact Format

The JSON artefacts containing the Clusters, Classes, Sub-classes, and Elements SHALL all have the same format as detailed in this section. Each activity is described fully by its cluster, class, sub-class, and element code numbers. When an activity is being used as a general term (or the detail is not sufficient to describe at all four levels) the upper levels can be used in place of the more specialized descriptions (by providing a zero value for the lower level code numbers). For example, Travel by sports car would be coded as cluster = 22, class = 2, subclass=1, element=1, while travel by land would be coded as cluster = 22, class = 2, subclass=0, element=0.

Value Name	Description	Type
name	The name of the everyday living activity.	String
cluster	The cluster code number of the activity.	Integer: 1..31
class	The class code number of the activity.	Integer: 0..99
subclass	The sub-class code number of the activity.	Integer: 0..99
element	The element code number of the activity.	Integer: 0.99

Examples:

[ …,

{"name": "Travel",

"cluster": 22, "class": 0, "subclass": 0, "element": 0}

…]

[ …,

{"name": "Travel by car",

"cluster": 22, "class": 2, "subclass": 1, "element": 0}

…]

4 Description of taxonomy

To provide a human readable top level description of COEL, the following table provides names of and longer form descriptions of the COEL Clusters. Note that any apparent logical ambiguities that can be suggested by these top level cluster names can be resolved by moving down in the hierarchy. Although structured for ease of use, the actual coherence of the COEL is guaranteed by the full set of elements.

COEL Cluster Name	Long Form Description
Personalcare	All self performed activities related to looking after yourself
Childcare	Activities related to looking after children
Adultcare	Activities related to looking after adults
Housework	Cleaning and day to day running of your dwelling
Maintenance	Functional upkeep of your dwelling and possessions
Animalcare	Activities related to looking after animals
Health	Activities related to "ormalized" your own health
Medicine	The diagnosis & treatment of ailments
Symptoms	Specific events related to symptoms of illness
Eating	The consumption of food items
Drinking	The consumption of liquid items
Cooking	The preparation of food and drink
Sleep	Activities related to preparing for sleep and the timecourse of sleep itself
Sports	Sports and predominantly physically active hobbies & pastimes
Hobbies	Sports and hobbies using vehicles / equipment
Spectator	Activities related to watching sports
Pastimes	Participatory pastimes (non-physically active)
Observer	Spectator pastimes (non-physically active)
Media	All activities involving the use of media.
Shopping	Activities involved in shopping for physical goods
Service	Activities involved in shopping for services
Travel	Moving from one place to another for a specific purpose
Communication	All methods of socially interacting via communicating face to face, non face to face and to groups & audiences
Device	Using electronic devices
Trials	Unplanned events which cause irritation or shock
Education	Activities involved with the ormalized process of acquiring knowledge
Accident	Accidents and injuries related to people
Lifestage	Life defining events
Lifestyle	Events related to lifestyle and type of person
Task	Generic work tasks
Work	Different types of work
Mood and Mind	Observable manifestations of emotion

4.1 Visualising the model

As a gracious and thoughtful service to users of COEL, a dynamic visual representation of the latest version of the full COEL model is provided at [Coelition].

5 Conformance

The Classification of Everyday Living model MUST conform to the conditions set out in Section 3.

Appendix A. Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Paul Bruton, Individual Member

Joss Langford, Activinsights

Matthew Reed, Coelition

David Snelling, Fujitsu

Appendix B. Revision History

Revision	Date	Editor	Changes Made
1	26/09/2015	Joss Langford	Artifact reference for 4 levels of COEL model added
2	6/10/2015	Matt Reed	Added explanatory material about COEL structure and knowledge base
3	14/10/2015	David Snelling	Review with some edits and the inclusion of the JSON format description.
4	19/10/2015	David Snelling	Minor additional changes,
5	31/10/2105	Joss Langford	Some text edits and additional diagrams added. Accept all changes, track changes off, check references and style consistency.
6	31/10/2015	David Snelling	Added references to json artefacts. Changes date to target of Nov 3.
7	25/11/2015	David Snelling	Set date for CD publication