New classes: sub-classes of site

[dr-shorthair]

Propose adding some specific sub-classes of site, to support description of data collection activities:

1. Fiat site designed to support sampling an ecosystem, bio/geophysical field, etc, with subclasses like

   • 0-D - station (where one or more instruments might be mounted temporarily or permanently)
   • 1-D - transect, flight-line, drill-hole, ship-track
   • 2-D - plot, quadrat, cross-section, scene
   • 3-D - point-cloud, representative volume
   • possibly 4-D (i.e. 3-D with time) etc Classification by topological dimension has precedents in CSML and O&M, and this classification supports some standard processing and visualization paradigms.

2. Trap

   • many kinds

[ramonawalls]

All sites are by definition 3 dimensional, but we could use the BFO subclasses of spatial region (http://purl.obolibrary.org/obo/BFO_0000006) to classify sites whose boundaries are defined by a 0 to 3 dimensional spatial region, and use spatiotemporal region (http://purl.obolibrary.org/obo/BFO_0000011) to define the 4D sites.

[pbuttigieg]

Punt to ENVO? We've dealt with some of this in the past. important to weave geospatial abstractions with physical entities carefully (no one really samples sites that are not fully spatially and temporarily expanded, but we abstract for convenience)

[ramonawalls]

I think a trap is subclass of material entity, because it always involves some kind of equipment to build the trap, even if its just sticks and leaves arranged in a particular way .

I think we can define the traps and sites at which they occur as separate instances, although we could certainly say (in the data) something like "Trap A located at site B" or "Site B contains trap A".

[ramonawalls]

@pbuttigieg, I'm fine with having these classes in ENVO, if you think they fit better there, although I think traps might fit better into BCO, because there are used in a type of sampling process that we will define in BCO.

[dr-shorthair]

The location of a site is always 3-D.

But its shape and extent is typically of a lower topological dimension, in ways that are often interesting for subsequent processing and analysis, and visualization.

e.g. variation of some property along a 1-D site is typically visualized as a varying offset curve relative to the axis of the samplingcurve, or as a variation of colour. The dimensional breakdown has a strong prior history.

[pbuttigieg]

@pbuttigieg, I'm fine with having these classes in ENVO, if you think they fit better there, although I think traps might fit better into BCO, because there are used in a type of sampling process that we will define in BCO.

We have them in our manufactured product hierarchy as a result of a user request some time back: http://purl.obolibrary.org/obo/ENVO_01000975

Along with things like cages: http://purl.obolibrary.org/obo/ENVO_01000922

I think BCO would be a more sensible place for traps used for collections. @ramonawalls I'm a little reluctant to obsolete a class that's in use, but it's something that users should be prepared for. I suggest you import manufactured product and then develop a trap hierarchy under it. Let me know when you're done and I'll obsolete the ENVO classes and add BCO's in the 'replaced by' field.

[pbuttigieg]

I think we can define the traps and sites at which they occur as separate instances, although we could certainly say (in the data) something like "Trap A located at site B" or "Site B contains trap A".

Definitely

[robgur]

I think a "trapping inventory process" is different from "traps". "Traps" are manufactured objects but a "trapping protocol" doesn't need to be a "trap" as we normally consider them - "camera traps" are not really traps, are they? But that still is a type of "trapping inventory process".

On Tue, Oct 9, 2018 at 11:33 AM Pier Luigi Buttigieg < notifications@github.com> wrote:

@pbuttigieg https://github.com/pbuttigieg, I'm fine with having these classes in ENVO, if you think they fit better there, although I think traps might fit better into BCO, because there are used in a type of sampling process that we will define in BCO.

We have them in our manufactured product hierarchy as a result of a user request some time back: http://purl.obolibrary.org/obo/ENVO_01000975

Along with things like cages: http://purl.obolibrary.org/obo/ENVO_01000922

I think BCO would be a more sensible place for traps used for collections. @ramonawalls https://github.com/ramonawalls I'm a little reluctant to obsolete a class that's in use, but it's something that users should be prepared for. I suggest you import manufactured product and then develop a trap hierarchy under it. Let me know when you're done and I'll obsolete the ENVO classes and add BCO's in the 'replaced by' field.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BiodiversityOntologies/bco/issues/86#issuecomment-428240099, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcc7FswHJpOTzEY3Q3LDsjILOBShCkbks5ujMHngaJpZM4WxbJv .

[ramonawalls]

@pbuttigieg Keeping manufactured product in ENVO makes sense, as does making classes in BCO for the kinds of traps and cages used in biological sampling. In fact, I don't see any problem with keeping manufactured cage and animal cage in ENVO, and then we can subclass those. Technologies for managing conflicting import chains are in fact getting better... But if you prefer BCO to host the general class, we can do that too.

And yes, per @robgur 's comment, the process of trap sampling is quite different from the trap itself, and I think BCO will need both of those. We can work with groups like @dr-shorthair 's colleagues to determine which hierarchy they should use for annotating data, if they don't want to go the whole triplification route.

[ramonawalls]

On another topic, my eyes were opened today on the RO calls, as the BFO developers explained the difference between site and spatial region (which are sibling classes of parent immaterial entity). Site is intended for use when refering to a non-material entity whose location is defined by a material entity or entities that bound it (e.g., a cavity). Spatial region is intended for an immaterial entities whose locations are defined by a coordinate system (e.g., geographic coordinates or the surface of the body, as two example). Therefore, I think we have often been using bfo:site in BCO where we should be using spatial region.

In the case of the new classes requested here, since they are defined by fiat, and usually on the surface of the earth, these will probably be spatial regions rather than sites.

[dr-shorthair]

Looks like this is a specialist use of the term 'site' in biomedical applications, which does not fully match its use in environmental sciences. While our sites are often specified using coordinates, they may be specified using topological relationships to other things in the environment. Which appears to include both of these cases.

(Ontology begets philosophy ... )

[ramonawalls]

Well, BFO is not supposed to be specific to biomedicine, but I completely agree that the word site is used quite differently in environmental sciences. In BCO, we can label our classes in a way that serves both our communities and semantic clarity (i.e., we can use the word site in the labels), so this should only affect the subclass hierarchy.

[dr-shorthair]

Sorry - I got that wrong - Ontology recapitulates ideology ...

[ramonawalls]

That does make more sense. :)

[ramonawalls]

Okay. Here is my assessment of @dr-shorthair's needs: a set of classes to describe sites (in the BFO sense, three dimensional) that are defined, per some protocol, by a 0-4 dimensional spatial or spatial temporal region.

The purpose of these classes is to conveniently describe the locations where observing or sampling processes take place. New classes are not strictly necessary, as instance data could be defined using combinations of BFO classes for immaterial entities, but having the classes will make it easier to define things like a site visit (issue #85), as well as the different types of sampling protocols we want to eventually include, when those sampling protocols take place in a 0-4 dimensional "site".

Assuming that I got the above assessment correct, then I suggest the addition of the following classes (names can be discussed, words in parenthesis are merely for clarity here, and won't be in the ontology)

environmental site: A site (bfo) that is part of some astronomical object (envo) and is described for the purpose of some planned process, often an observing or sampling process.

zero-dimensional environmental site: An environmental site that is described by some zero-dimensional spatial region (bfo). subClass of environmental site overlaps some zero-dimensional spatial region

one-dimensional environmental site: An environmental site that is described by some one-dimensional spatial region (bfo). subClass of environmental site overlaps some one-dimensional spatial region

two-dimensional environmental site: An environmental site that is described by some two-dimensional spatial region (bfo). subClass of environmental site overlaps some two-dimensional spatial region

three-dimensional environmental site: An environmental site that is described by some three-dimensional spatial region (bfo). subClass of environmental site overlaps some three-dimensional spatial region

four-dimensional environmental site: An environmental site that is described by some spatio-temporal region (bfo). subClass of environmental site overlaps some spatio-temporal region

I'm not 100% sure about the overlaps relation. It is true, but not so strong. However, I am disinclined to make up a new relations more specific to what we are defining. What do you think, @pbuttigieg?

[ramonawalls]

@pbuttigieg In issue #85 you mentioned defining these sites as subclasses of envo: astronomical body part, rather than of bfo: site, but astronomical body part is a material entity, and I think we are describing a non-material entity here (which may overlap some material entity).

[ramonawalls]

Also, examples will be important here. For example, the site of monitoring sensor for 0-dimensional environmental site, the a line transect as an example of a two-dimensional site (which is probably intended as a sample of a spatio-temporal region).

[cmungall]

Are you sure you want to use BFO spatial regions?

I'm also worried by the potential for reciprocal dependency between two ontologies. We need to think about modularization here.

[dr-shorthair]

Thanks @ramonawalls - yes, I think you have nicely re-formulated the requirement that I outlined at the top of this issue.

FWIW this taxonomy of site-types, classified by topological dimension, is in ISO 19156 (see Figure 11 page 25), which in turn was inspired by prior work in the fluid-earth-science community (oceans and atmospheres).

[dr-shorthair]

Note that the link above is to the OGC copy of ISO 19156, which is not paywalled.

[ramonawalls]

@cmungall Do you suggest another way to define 0-4 dimensional regions? The BFO classes seemed clear and straight forward, but maybe there are some entailments I am not aware of?

In terms of reciprocal dependencies, are you thinking of between ENVO and BCO? This is a big area right now that we need to work out, as both of us seem to be developing along the same lines. We should hash out what will go where.

Also, any pointers (i.e. papers or blogs) for modularity you recommend?

[cmungall]

I need to go back and read the docs again but was suspicious of the whole regions "not moving" thing and frames of reference. Curious if you used these in your space ontologies.

I also believe that committing to fine-grained upper ontology distinctions comes with a cost and not much value. I need to write this up. Minimally, you will have to have the overhead of a new set of relations for connecting these entities together and figuring out how these relations chain with no other relations. I see no harm in not committing or in committing to site for these

We have managed in uberon for years with lines and planes and no commitment to spatial regions:

https://www.ebi.ac.uk/ols/ontologies/uberon/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FUBERON_0006800

You can watch me repeat the same points over on this thread: https://github.com/OBOFoundry/Experimental-OBO-Core/issues/11

Modularity.. just this doc which you have seen: https://docs.google.com/document/d/1i0-mj_gY42h9Ko8ij4SQ4LvCAXKCRwXXSAFyNsbQomU/edit