humanbehaviourchangeproject / ontologies Goto Github PK

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.

To enhance the maintainability the components should be restructured or refactored.

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.

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

It is better if we keep only the current active one. The historical versions can still be browsed in the Git history.

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.

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.

on OLS the ontology URI is reported as http://humanbehaviourchange.org/ontology/bcio.owl but this doesn't resolve to OWL

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!

Remove intermediate 'inputs' directories that sometimes occur.

Match spreadsheet name with generated OWL file name.