Review and comments on Plot-X

2021-07-20 Simon J D Cox

2021-07-29

Plot-X data model
Plot-X examples
TERN Ontology

Plot-X and TERN Ontology appears to be a fairly faithful implementation of parts of the model proposed in [TERN-Plot]https://ternaustralia.github.io/ontology_tern-plot/, including the Project, Site and SiteVisit classes, with Feature, Observation, Sampling from https://www.w3.org/TR/vocab-ssn/ .

These comments pick out a few places where minor changes might be beneficial.

Keys and IDs

The Plot-X model follows E-R conventions, where both Primary- and Foreign-keys are given a name AaaBbbID.

Note that in an RDF implementation, the link from one resource (entity) to another will be through an 'object-property' which should have a name like hasCccDdd or isEeeGggOf whose value is the URI (identifier) of the target resource (entity). i.e. Don't put 'ID' in the name of RDF properties acting as pointers to other resources ('foreign keys').

AaaBbbID should be reserved for the assigned identifier, else it is confusing.

Site

  • swPoint - this is an unusual anchor point, it is more common to specify centroid. But OK.

  • siteType - (site, transect, quadrat) - for a small set of types these can be implemented as separate classes, sub-classes of a genericSite class (rename the parent class).

  • rename dimensionextent

Feature

  • (latitude, longitude, elevation) - Consider linking to a (3D?) Point instead - i.e. maintain a separate Point table

  • what is the distinction between elevation vs altitude? and depth? They are all vertical coordinates. (Is depth measured positive down?)

featureType == domain feature type. While we want to take the featureType value from a CV (i.e. do not have an explosion of sub-classes) it would also be useful to specify the expected Observations for each type (e.g. tree always has height, DBH etc). This corresponds to some kind of constraints on the observableProperties per feature-type.

Observation

Some attribute names are inconsistent with O&M/SOSA

  • parameter instead of sosa:observedProperty

  • method instead of sosa:usedProcedure

  • instrumentType + observer instead of sosa:madeBySensor

Sampling

  • sampleFeatureID appears to appear in place of sosa:result

Is there a separate table/class for samples, or does this attribute just loop back to another row in the Feature table (I'm not fully familiar with E-R diagrams)

Sample

Need to clarify the relationship between ‘voucher’ and Sample - is it a sub-class?

*Attribute

  • Why is the value attribute called 'result'? Rename to hasValue.

  • Is there a relationship between *Attribute::attribute and Observation::parameter?

hasSite

TERN Ontology hasSite appears in multiple places, as a convenience-property from Sampling, Observation, FeatureOfInterest, as well as from SiteVisit. I suggest removing the redundant uses, and only retaining the use from SiteVisit to Site, since these other usages correspond to property-paths via SiteVisit anyway - note that SPARQL property-paths are much cheaper than SQL JOIN operations.

 

We at TERN acknowledge the Traditional Owners and Custodians throughout Australia, New Zealand and all nations.
We honour their profound connections to land, water, biodiversity and
culture and pay our respects to their Elders past, present and emerging.

TERN is supported by the Australian Government through the National Collaborative Research Infrastructure Strategy, NCRIS.