NTR: create classes for monitoring processes and sites

[pbuttigieg]

xref:https://github.com/BiodiversityOntologies/bco/issues/82

We need planned processes to account for monitoring activities, within which site visits and associated processes (e.g. equipment deployment and maintenance) can be nested.

[ramonawalls]

I wonder if environmental monitoring might fit better in BCO, which aims to describe similar processes, especially since much of environmental monitoring is done to study biodiversity or biologically driven processes.

[pbuttigieg]

If BCO is focused on biology, then no, this would be too broad. Subclasses that deal with biodiversity could work in BCO however. We'll need those for the EBVs, but we should coordinate with ECOCORE.

[dr-shorthair]

I understood that ENVO was for the natural systems, and BCO for human-directed activities concerned with observing and sampling the natural system. So I would expect to see monitoring processes and sites in BCO.

[pbuttigieg]

ENVO has included anthropised environments and sites since its creation as well as human-driven processes for several years. It does't make sense to keep these apart from the "natural" world on this planet. Its basal semantics make it the appropriate place for handling sites that overlap with environments and ecosystems. I could see that the abstractions (transects, 2D sweeps, etc) could go into a more BCOish resource, but that resource should be higher level (see below) .

BCO is/was scoped for biological entities. Those looking for environmental monitoring terms would go to an environment ontology which would create subclasses under an imported 'observing process' from some higher-level ontology. This makes the import chain unidirectional and avails of denser axioms in the importing resource. It would be ideal if a module of BCO's top level semantics (not bound to any domain) is made into its own small ontology. BCO can then import it to handle biological obs/sampling (coordinating with UBERON, GO etc) and ENVO the environmental equivalents. Otherwise we'll face an OBI-like situation which will set us up for more autophagic import issues.

On Mon, 8 Oct 2018, 03:04 Simon Cox, notifications@github.com wrote:

I understood that ENVO was for the natural systems, and BCO for human-directed activities concerned with observing and sampling the natural system. So I would expect to see monitoring processes and sites in BCO.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/624#issuecomment-427702073, or mute the thread https://github.com/notifications/unsubscribe-auth/ACK7MqWVrk6h4BHdk6gmPStinSikY_1Bks5uiqR_gaJpZM4WHU5W .

[ramonawalls]

I see the point of having a broader class for monitoring processes and site visits, but I wonder if OBI wouldn't be a better home for those than ENVO or BCO? Despite it's name, OBI has a number of high level classes that are not specific to biomedicine. These classes might even be better in the proposed OBO core (between BFO and domains) ontology, but I don't want to delay waiting for those.

@pbuttigieg and @dr-shorthair , can you say what differentiates a monitoring process from a more general observation? Is it a matter of scheduled, repeated observations, or is there more to it?

Note also that according to obi-ontology/obi#969, I will be working on solid definitions for observing process and observing process based on sampling, so we should coordinate this need with those.

@pbuttigieg I really like the idea of having a sort of domain-less bco-core (maybe called something other than bco-core) with the basic semantics for sampling, observing, specimen collection, etc. Let me start an issue for that, so we can discuss it separately.

Also tagging @robgur on this ticket, in case he doesn't follow ENVO.

[dr-shorthair]

+1 to looking at OBI as home for generic observation and sites classes.

A monitoring process is an observation process whose result is a longitudinal time series. The end time/date might be unspecified (i.e. not yet known).

+1 to bco-core / obo-core

[pbuttigieg]

I see the point of having a broader class for monitoring processes and site visits, but I wonder if OBI wouldn't be a better home for those than ENVO or BCO? Despite it's name, OBI has a number of high level classes that are not specific to biomedicine. These classes might even be better in the proposed OBO core (between BFO and domains) ontology, but I don't want to delay waiting for those.

@ramonawalls This is pretty much what I suggest above, but more friendly to dumping this in OBI . Note that the Library been putting this off budding key modules from OBI for a while. I understand the practical argument, but I still feel uneasy.

@cmungall what do you think of a high-level and small observation module branching off of OBI? Is the time right? This is similar to the "protocol" discussion we had. See below for @ramonawalls point on some sort of obs/sampling-core.

Perhaps the OBO-core is the place for this.

@pbuttigieg and @dr-shorthair , can you say what differentiates a monitoring process from a more general observation? Is it a matter of scheduled, repeated observations, or is there more to it?

A monitoring process is an observation process whose result is a longitudinal time series. The end time/date might be unspecified (i.e. not yet known).

Agreed with @dr-shorthair. Usually monitoring processes are also directed at one or more indicators, otherwise it's more vanilla long-term observation. So I could imagine:

• long-term observation process
  • monitoring process

Note also that according to obi-ontology/obi#969, I will be working on solid definitions for observing process and observing process based on sampling, so we should coordinate this need with those.

+1 Shall we have a call and generate a consensus to push?

@pbuttigieg I really like the idea of having a sort of domain-less bco-core (maybe called something other than bco-core) with the basic semantics for sampling, observing, specimen collection, etc. Let me start an issue for that, so we can discuss it separately.

+1 This will help untangle things quite a bit.

Also tagging @robgur on this ticket, in case he doesn't follow ENVO.

:scream:

[ramonawalls]

+1 Shall we have a call and generate a consensus to push?

Let me create some draft definitions, then I will try to set up a call in a week or two.