humanbehaviourchangeproject / ontologies Goto Github PK

A repository for the BCIO ontology

Python 95.68% Shell 4.32%

ontologies's Introduction

Welcome to the repository for the Behaviour Change Intervention Ontology (BCIO)

The Human Behaviour-Change Project is a collaboration to synthesise what we know about behaviour change. It is a collaboration between behavioural scientists and systems architects at University College London and computer scientists at IBM Research, Dublin.

The overall aim of the Human Behaviour-Change Project is to automate evidence searching, synthesis and interpretation to rapidly address questions from policy-makers, practitioners and others to answer ‘What works, compared with what, how well, with what exposure, with what behaviours (for how long), for whom, in what settings and why?’. To achieve this, evidence needs to be organised ontologically, i.e. associated with a shared formal description of entities and relationships capturing domain knowledge in order to enable aggregation and semantic querying. We are creating the Behaviour Change Intervention Ontology (BCIO) to do this.

Here you will find files of completed ontologies within the overarching BCIO. To date, completed ontology files include: Upper-Level BCIO: Overall structure of the Behaviour Change Intervention Ontology Setting: An aggregate of entities that form the environment in which a BCI is provided

You can also find the scripts used to generate OWL files for each ontology [scripts folder].

Issue tracking

You can report any issues with ontology files here: https://github.com/HumanBehaviourChangeProject/ontologies/labels

How is the Behaviour Change Intervention Ontology (BCIO) being developed?

You can find methods used to develop the ontology on the Open Science Framework: https://osf.io/86m75/ Papers for each ontology will be published on Wellcome Open Research and updated here when available.

Relevant resources

Michie, S. et al. (2017). The Human Behaviour-Change Project: harnessing the power of artificial intelligence and machine learning for evidence synthesis and interpretation. Implementation Science, 12(1), 121.

Norris, Kelly & Michie. (2018). New AI system will help us discover the most effective behaviour change strategies. The Conversation. https://theconversation.com/new-ai-system-will-help-us-discover-the-most-effective-behaviour-change-strategies-100057

Norris, E., Finnerty, A. N., Hastings, J., Stokes, G., & Michie, S. (2019). A scoping review of ontologies related to human behaviour change. Nature Human Behaviour, 3(2), 164-172.

Project website: https://www.humanbehaviourchange.org/ For more information, please contact [email protected]

GitHub contributors: Janna Hastings, Ailbhe N. Finnerty, Emma Norris

Project Investigators: Susan Michie, Pol Mac Aonghusa, James Thomas, Michael P. Kelly, Marie Johnston, John Shawe-Taylor, Robert West

Ontology development team: Ailbhe N. Finnerty, Emily Hayes, Candice Moore, Emma Norris, Alison J. Wright, Silje Zink

ontologies's People

Contributors

Stargazers

Watchers

Forkers

jannahastings prei007 b-gehrke nitinbharadwajnataraj zaidishz ontology-tools

ontologies's Issues

fitting an occupation holder class into BFO/OBO and BCIO?

I'm wondering about how an occupation holder class, e.g. plumber, architect, hazardous material handler etc. would fit into BFO/OBO and BCIO? I’m wondering if a combination of BCIO’s process aggregate and UBERON (and others) "processual entity" and OBI “has performer” may work?

BCIO’s process aggregate idea encompasses more than one process: “Process aggregate extends BFO in the same way that object aggregate extends its coverage of material entities.”

UBERON processual entity (A term that should migrate to COB?): “An occurrent that exists in time by occurring or happening, has temporal parts and always involves and depends on some entity.”

OBI has performer (And we should have OBI add inverse “performer of”?)

Then perhaps:

occupation: a process aggregate which has as parts processual entities which are occupational services all provided by one performer.

occupational service: a processual entity performed by an occupation holder and which [provides outputs to or removes inputs from] some recipient of the service.

occupation holder: A material entity which is a “performer of” some occupational service.

An occupation holder could then map to a segment of a human’s (or possibly, funnily enough robot’s) existence. Its awkward dealing with a 3D ontology, but to map “occupation holder” to a human being for some duration(s) of time (akin to a life stage), probably need an object property named something like “congruent with at some time” to enable “occupation holder ‘congruent with at some time’ some Homo Sapiens”. Not sure if something like that exists in RO though?

Damion

Dual inheritance

Hello, I was checking out the ontology and noticed BCIO_050316, labelled "behavioral disposition", is a subclass of both 'bodily disposition' and 'information content entity', creating issues of dual inheritance. Is this an issue? Is the term used in a way that avoids issues?

Thank you!

Adding new classes still not working properly

When adding new classes the first time I go to 'save' it hangs, then it works if I do it again but the numbers assigned to the new classes as not unique. The same problem occurs with AddictO.

Several fields in Upper Rels are not released

The columns Definition, Range, and Domain are not included in the release. Problems occur because of the mutual dependencies of Upper Defs and Upper Rels.

Release workflow: simplify upper level parsing and release

Currently parsing and releasing the BCIO upper level consists of several steps, including that we parse the BCIO Upper Defs spreadsheet and merge the content with the spreadsheet of extracted relations from LucidChart to create the BCIO Upper Level Merged spreadsheet. However, there is a bug in this process in that the merged file does not contain the correct status flags as are specified the original Upper Defs spreadsheet. In addition, the LucidChart upper levle visualisation is not editable by all team members. Thus, to simplify the release workflow, suggest that the Upper Level Merged file be corrected and then the Upper Defs file be removed. Thereafter, users can edit the Upper Level Merged file directly including maintaining status and relationships.

is-about

In the paper https://wellcomeopenresearch.org/articles/6-77/v1 I read " The relationship ‘is_about’ from the Information Artifact Ontology (Ceusters, 2012) was also used to represent one class presenting information about another (e.g Total number of people able to deliver intervention is_about Source)." I don't find this relational expressed in the BCIO version here, so perhaps it is not an issue. But note that if you intend to do so as in the paper, it wouldn't work under the BFO principles: since 'source' is defined in the paper as 'role played by a person', so you would be specifying how many distinct intervention roles one specific person has. Linking it to 'person' would also not work, as the total number of an instance of 'person' is 1. The range of the relation in your example would be an aggregate of persons.