search

ternaustralia / ontology_tern

TERN Ontology
https://linkeddata.tern.org.au/viewers/tern-ontology
Creative Commons Attribution 4.0 International
6 stars 4 forks source link

Site-visit model appears to be incomplete #186

Open dr-shorthair opened 2 years ago

dr-shorthair commented 2 years ago

The 'site-visit' appears to be an important element of the practice of ecology observations and sampling. However, it looks like it is a bit underdone in the TERN Ontology. In particular, there is no explicit relationship between the SiteVisit and Site classes.

So in a SOSA/TERN Ontology aligned to the PROV model, a Site is a kind of prov:Entity, and a SiteVisit is a kind of prov:Activity.

A SiteVisit occurs at a Site, and groups a set of Observations and Samplings. All of these are kinds of prov:Activity so there is a 'sub-activity' relationship between them - maybe dcterms:isPartOf or maybe something more specialized.

The generic relationships between an Activity and an Entity are prov:used and prov:wasUsedBy. So the hasFeatureOfInterest property from an Observation or Sampling could be a sub-property of prov:used. This could also be used to link a SiteVisit to its Site.

I note that you have taken some shortcuts with locationDescriptiopn and siteDescription duplicated on both Site and SiteVisit. Probably this information is more strictly associated with only the Site, which might be described and located once, and then re-visited more than once. Time-varying descriptive information is strictly the result of Observations made as part of a SiteVisit.

I realize that this is a stricter model than you have used until now.

edmondchuc commented 2 years ago

In particular, there is no explicit relationship between the SiteVisit and Site classes.

The mandatory relationship was removed to support opportunistic surveys. Instead of the ultimate feature of interest being an established survey site for samplings and observations, the ultimate feature of interest is now the next closest spatial region, e.g. a national park, state or territory.

Perhaps site visits should always exist and their relationship may not necessarily point to a Site but can also point to some other FeatureOfInterest like a national park. There is still an inherent "site visit" to some spatial region. What do you think?

I note that you have taken some shortcuts with locationDescriptiopn and siteDescription duplicated on both Site and SiteVisit.

Probably this information is more strictly associated with only the Site, which might be described and located once, and then re-visited more than once.

Time-varying descriptive information is strictly the result of Observations made as part of a SiteVisit.

I think siteDescription and locationDescription should be factored out into observable properties. Plus they are really only applicable to the AusPlots Rangelands collection protocol.

These two properties snuck in from a few years ago when we were still figuring out how to model things.

dr-shorthair commented 2 years ago

can also point to some other FeatureOfInterest like a national park. There is still an inherent "site visit" to some spatial region. What do you think?

Yes - that would work. Else you just accept that the national park also becomes a tern:Site by virtue of being the object of the tern:visitedSite property. That is simple RDFS entailment, and does no harm.

What I was hoping to find was SiteVisit as a basic type that allows for a set of observations and samplings (and perhaps even treatments...) to be collected together as part of a coordinated activity. That is how they are undertaken in practice, but it looked like it was downgraded in the overall ontology.

In order to accomplish this, you would also need to add some guidance about the associations between these different activities. PROV-O has only prov:wasInformedBy and prov:qualifiedCommunication, neither of which really works. In the Project Ontology (which is another PROV application) I added https://linked.data.gov.au/def/project#wasSubActivityOf and its inverse https://linked.data.gov.au/def/project#hadSubActivity though perhaps dcterms:isPartOf/dcterms:hasPart would do.