FDRI Metadata Ontology

Introduction

This document has been created to further discussion on the design of the model for the FDRI metadata store. It outlines a model designed to make use of existing standards such as DCAT, PROV-O, SOSA/SSN and i-Adopt as far as is practical.

DCAT provides the concepts of Dataset, DataService and a catalog consisting of records of resources which are managed separate from the resources they describe. PROV-O provides a model of activities that create, modify and use entities and that are associated with Agents (both human and non-human) who perform or otherwise participate in those activities. SOSA/SSN provides the notions of observable properties as things that can be measured by sensors against some feature of interest. i-Adopt provides the foudation for structuring the definition of observable properties.

GitHub Repository

The FDRI ontology and its documentation are maintained at https://github.com/NERC-CEH/fdri-ontology

The latest releases are available at https://github.com/NERC-CEH/fdri-ontology/releases and include the OWL ontology ( fdri-metadata.ttl ), and the version of this documentation that goes with the release as a zipped package ( doc.tar.gz ).

Note on diagrams

UML class diagrams have been used extensively to document model design. Familiarity with UML class diagram notation is assumed. Examples of how the model is intended to be used are diagrammed in a simpler flowchart notation.

Due to a limitation with MermaidJS which is used to render the diagrams, the names of properties on relations in UML diagrams are written with an underscore between the prefix and the local part of the identifier rather than the traditional colon character.

Namespaces Used

This document uses the following namespaces:

Prefix URI Source
adms http://www.w3.org/ns/adms# Asset Description Metadata Schema
dcat http://www.w3.org/ns/dcat# Data Catalog Vocabulary (DCAT) - Version 3
dct http://purl.org/dc/terms/ DCMI Metadata Terms
iop https://w3id.org/iadopt/ont/ i-ADOPT Framework Ontology
prov http://www.w3.org/ns/prov# PROV-O: The PROV Ontolog
foaf http://xmlns.com/foaf/0.1/ FOAF Vocabulary Specification 0.99 (Paddington Edition)
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF 1.1 XML Syntax
rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema 1.1
sosa http://www.w3.org/ns/sosa/ Semantic Sensor Network Ontology
ssn http://www.w3.org/ns/ssn/ Semantic Sensor Network Ontology
time http://www.w3.org/2006/time# Time Ontology in OWL
vcard http://www.w3.org/2006/vcard/ns# vCard Ontology - for describing People and Organizations
xsd http://www.w3.org/2001/XMLSchema# W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes

In addition the prefix fdri is used to refer to the namespace for the FDRI metadata model. This namespace has not yet been assigned.

Programme Catalog Structure

The fine-grained metadata store will maintain a separate fdri:ProgrammeCatalog for each environmental monitoring programme that provides data through FDRI.

fdri:ProgrammeCatalog extends dcat:Catalog to capture configuration information regarding the metadata stored for a particular ef:MonitoringProgramme . This configuration information defines the concept schemes, observed properties and annotation properties used in the metadata structures for the programme and allows these to vary on a per-programme basis as needed.

classDiagram direction LR class Catalog["dcat:Catalog"] class ProgrammeCatalog["fdri:ProgrammeCatalog"] class Programme["ef:MonitoringProgramme"] Catalog <|-- ProgrammeCatalog ProgrammeCatalog --> Programme: fdri_programme ProgrammeCatalog --> VariableScheme: fdri_observedPropertyScheme ProgrammeCatalog --> VariableScheme: fdri_annotationPropertyScheme ProgrammeCatalog --> RegionScheme: fdri_regionScheme ProgrammeCatalog --> CatchmentScheme: fdri_catchmentScheme ProgrammeCatalog --> ConfigurationPropertyScheme: fdri_configurationPropertyScheme ProgrammeCatalog --> EnvironmentalMonitoringFacilityTypeScheme: fdri_monitoringFacilityTypeScheme ProgrammeCatalog --> EnvironmentalMonitoringFacilityTypeScheme: fdri_monitoringSystemTypeScheme

Scheme Properties

Property Value
fdri:observedPropertyScheme The list of observed properties which are measured by the programme.
fdri:annotationPropertyScheme The list of metadata annotations which may be used in the metadata records for sites, stations and sensors associated with this programme.
fdri:regionScheme The list or hierarchy of geographic regions covered by this programme.
fdri:catchmentScheme The list or hierarchy of hydrographic catchment areas covered by this programme.
fdri:configurationPropertyScheme The list of sensor (or system) configuration properties applied to the sensors (or systems of sensors) used by this programme.
fdri:monitoringFacilityTypeScheme The scheme of concepts that define types of network sites and stations participating in the programme.
fdri:monitoringSystemTypeScheme The scheme of concepts that define the types of sensors and sensor systems used by the facilities that participate in the programme.

NOTE There are no maximum cardinality constraints on these scheme refernce properties, allowing them to be repeated to indicate that values may come from several different concept schemes.

NOTE For this release of the model we have decided that the schema should not mark any of these properties as required. As we establish more concretely how the properties will be used by downstream applications we can tighten constraints and mark some properties as required in future releases.

NOTE The properties listed above do not include additional concept schemes which are used indirectly, such as the fdri:ObjectOfInterestScheme and fdri:ContextObjectScheme that are used by the Complex Observable Properties defined in the fdri:VariableScheme .

QUESTION Now that there is a mechanism for annotations do we want to drop the specific catchment and reigon relations in favour of using annotations for those instead? If we do that though, how do we identify those annotation properties that provide geospatial information for resources?

Other Properties

Property Value
fdri:programme References the ef:MonitoringProgramme whose observations are recorded as datasets in this catalog.

High Level Catalog Structure

Catalogued Items

In addition to dcat:Dataset and dcat:DataService , a subset of assets are also treated as catalog resources. This allows a (possibly separate) cataloguing of assets such as sensors, systems (packages of sensors), platforms (e.g. vehicles, physical infrastructure on a site). Each catalogued resource has its own catalog record, which makes it possible to distinguish between activities which affect the thing from those which affect the recorded metadata about the thing.

For example an ingest process that reads a spreadsheet list of sensors would be an activity that generates/updates the record of the sensor; whereas an activity of maintaining a sensor would be an activity that updates the sensor itself.

NOTE The scope of which assets are catalogued in this way is open to dicsussion. For example, catchment areas and regions are not currently included here as it is assumed that these might be mastered and controlled externally.

classDiagram direction LR class ProgrammeCatalog["fdri:ProgrammeCatalog"] class Catalog["dcat:Catalog"] class CatalogRecord["dcat:CatalogRecord"] class CatalogResource["dcat:CatalogResource"] class Entity["prov:Entity"] class Facility["fdri:EnvironmentalMonitoringFacility"] class DataService["dcat:DataService"] class Dataset["dcat:Dataset"] class Agent["fdri:Agent"] class DataProcessingConfiguration["fdri:DataProcessingConfiguration"] class Procedure["fdri:Procedure"] ProgrammeCatalog--|> Catalog Catalog --|> CatalogResource Entity <|-- CatalogRecord Entity <|-- CatalogResource Catalog --> CatalogRecord : dcat_record CatalogRecord --> CatalogResource: foaf_hasPrimaryTopic CatalogResource <|-- Dataset CatalogResource <|-- DataService CatalogResource <|-- Facility CatalogResource <|-- Agent CatalogResource <|-- Procedure CatalogResource <|-- DataProcessingConfiguration

The types shown in the diagram above are just the top-level elements of the model. More detail about these types can be found in the following sections of this document.

Concept Types and Concept Schemes

Reference data that is not covered by more domain-specific models (such as the EMF model) is modelled using concepts from SKOS, in particular skos:Concept and skos:ConceptScheme . We use specialisations of these two classes to denote specific types of concept and to use the model to define the appropriate place(s) where these concepts can be used.

The diagram below shows a simple example of this strucute. The type fdri:EnvironmentalMonitoringFacilityType is a skos:Concept that is used specifically to defined classes of environmental monitoring facility. The concept scheme that contains these definitions is typed as an fdri:EnvironmentalMonitoringFacilityTypeScheme which is a skos:ConceptScheme restricted to containing only fdri:EnvironmentalMonitoringFacilityType concepts.

For the FDRI model, a skos:ConceptScheme is treated as a dcat:Resource in a dcat:Catalog which provides facilities for recording additional metadata about each concept scheme.

classDiagram class Concept["skos:Concept"] class ConceptScheme["skos:ConceptScheme"] class Resource["dcat:Resource"] class EMFacilityType["fdri:EnvironmentalMonitoringFacilityType"] class EMFacilityTypeScheme["fdri:EnvironmentalMonitoringFacilityTypeScheme"] Resource <|-- ConceptScheme Concept <|-- EMFacilityType ConceptScheme <|-- EMFacilityTypeScheme EMFacilityType --> EMFacilityTypeScheme: skos_inScheme

The following table lists the subclasses of skos:Concept which are defined in the FDRI model.

Concept Type Concept Usage
fdri:Catchment A catchment area under observation by some EnvironmentalMonitoringFacility .
fdri:Variable A faceted type describing the properties of some EnvironmentalDomain which can be observed by an EnvironmentalMonitoringSystem .
fdri:ConfigurationProperty A property of an environmental monitoring system which can be configured with different values (e.g. installed firmware version)
fdri:ContextObject The context within which a Variable is measured.
fdri:EnvironmentalDomain The domain of the environment that an EnvironmentalMonitoringFacility monitors.
fdri:EnvironmentalMonitoringFacilityType The class of an EnvironmentalMonitoringFacility . Direct instances of this class are intended to apply to EnvironmentalMonitoringSite and EnvironmentalMonitoringPlatform .
fdri:EnvironmentalMonitoringSystemType The class of an EnvironmentalMonitoringSystem . This is defined as a subclass of EnvironmentalMonitoringFacilityType but is intended to capture sensor package types, broad categories of sensor and individual sensor models.
fdri:LandCoverType The category of land cover that apply at an EnvironmentalMonitoringSite
fdri:ObjectOfInterest The kind of entity measured by a Variable
fdri:ProcedureType The category of process that is applied to or carried out on an EnvironmentalMonitoringSystem (e.g. installation, calibration)
fdri:ProcessingLevel The level of processing applied to the measurements in an ObservationDataset
fdri:Region The geospatial region under observation by some EnvironmentalMonitoringFacility
fdri:RelatedPartyRole The role that some agent (and individual or organisation) plays in relation to an EnvironmentalMonitoringFacility .
fdri:SensorStatus The operational status of an EnvironmentalMonitoringSensor
fdri:SoilType The category of soil type at an EnvironmentalMonitoringSite
fdir:ValueStatistic The category of aggregation applied to a set of values in order to produce an aggregate dataset e.g. mean, min, max etc.

NOTE There are still a number of classes where instances are used as reference data that are currently neither a dcat:Resource nor a skos:Concept . Do we need to partition these remaining classes along these lines? * fdri:EnvironmentalMonitoringProgramme * fdri:GeospatialFeatureOfInterest

Basic Dataset Metadata

Core dataset metadata is modelled using concepts from DCAT with some extensions to capture FDRI-specific dataset types. In the diagram below only a fdri:ObservationDataset is shown but it is expected that this class hierarchy will be fleshed out in dialog with FDRI users and team members.

Quality metrics over datasets are modelled as sosa:Observation instances with a sosa:hasFeatureOfInterest of the dcat:Dataset . This means that quality metric definitions can be managed as a subset of the observed properties for FDRI. Metrics that cover a time slice of the dataset (e.g. daily data availabilty metrics) can be modelled as sosa:Observation with a sosa:phenomenonTime specifed as a time:Interval which defines the bounds of the slice.

Related datasets are gathered together using the DCAT dcat:DatasetSeries type to represent the group of datasets and the dcat:inSeries relation to relate a dataset to the series that it is a part of. A dataset may be in multiple series - e.g. a time-series of air temperature measurements from an FDRI weather station may be a member of a series of all measurements from that station (which may in turn be a member of a series of all measurements from the site), and may also be a member of a series of all air temperature time series from all stations in the FDRI network. Dataset series should be soft-typed with dct:type using a taxonomy of series types to be defined by the project to make it easy to distinguish between different types of dataset series (e.g. StationDatasetSeries, SiteDatasetSeries, NetworkDatasetSeries, NetworkVariableDatasetSeries).

The property fdri:originatingFacility can be used to reference the EnvironmentalMonitoringFacility from which observations contained in the dataset have come. The choice of facility should be a facility permanently associated with the observations in the dataset, so prefer the site at which the sensor equipment is located over sensors or packages which may be replaced without starting a new dataset. This property may also be used with fdri:ObservationDatasetSeries in which case the referenced facility should be the EnvironmentalMonitoringSite for a series soft-typed as SiteDatasetSeries , or the EnvironmentalMonitoringStation for series soft-typed as StationDatasetSeries .

The property fdri:originatingProgramme can be used to reference the EnvironmentalMonitoringProgramme from which observations contained in the dataset have come. This provides a more direct way to group datasets from the same programme than going via the fdri:ProgrammeCatalog

NOTE The use of dataset-level quality metric observations can be reserved for aggregate metrics such as data availability metrics. Row-level metrics could (and arguably should) be managed in the underlying data store.

classDiagram class CatalogResource["dcat:CatalogResource"] class Concept["skos:Concept"] class ConceptScheme["skos:ConceptScheme"] class ObservedProperty["iop:Variable"] class Measure["fdri:Measure"] class Program["fdri:EnvironmentalMonitoringProgramme"] class Facility["fdri:EnvironmentalMonitoringFacility"] class Agent["fdri:Agent"] class GeospatialFeatureOfInterest["frdi:GeospatialFeatureOfInterest"] class QualityObservation["fdri:QualityObservation"] class Dataset["dcat:Dataset"] class ObservationDataset["fdri:ObservationDataset"] class ObservationDatasetSeries["fdri:ObservationDatasetSeries"] class DatasetSeries["dcat:DatasetSeries"] class Dataset { dct_accrualPeriodicity: dcterms:Frequency dct_temporal: dct:PeriodOfTime dct_temporalResolution: xsd:duration } class CatalogResource { dct:title: rdf:langString dct:description: rdf:langString dct:accessRights: dct:RightsStatement dct:license: dct:LicenseDocument dct:rights dct:RightsStatement dct:conformsTo: dct:Standard dct:contactPoint: vcard:Kind dct:issued: xsd:dateTime dct:modified: xsd:dateTime dct:language: xsd:anyURI dct:identifier: rdfs:Literal dct:version: rdfs:Literal adms:versionNotes: rdfs:Literal } CatalogResource <|-- Dataset Concept --> ConceptScheme: skos_inScheme ObservationDataset --> GeospatialFeatureOfInterest : dct_spatial Dataset <|-- ObservationDataset DatasetSeries <|-- ObservationDatasetSeries ObservationDataset <|-- ObservationDatasetSeries CatalogResource --> Concept: dct_theme ObservationDataset --> ObservedProperty: sosa_observedProperty ObservationDataset --> Measure: fdri_measure ObservationDataset --> Facility: fdri_originatingFacility ObservationDataset --> Program: fdri_originatingProgramme CatalogResource --> Agent: dct_creator CatalogResource --> Agent: dct_publisher DatasetSeries --|> Dataset Dataset --> DatasetSeries: dcat_inSeries CatalogResource --> Concept: dct_type QualityObservation --|> Observation QualityObservation --> Dataset: sosa_hasFeatureOfInterest

QUESTION Do we need a cleaner separation between geospatial regions/points and abstract features of interest.

QUESTION Other than processing level what quality observations are planned for FDRI datasets? If it is only processing level, and new kinds of observation are not planned then perhaps a direct property (on fdri:ObservationDataset) would be a better choice.

QUESTION

Is there value in subclassing dcat:DatasetSeries . Do we expect aggregated metadata such as a list of fdri:programme and sosa:observedProperty from the fdri:ObservationDataset s in a series to appear on the parent series? If we do want a subclass is it one for each subclass of fdri:ObservationDataset (and any other subclasses of dcat:Dataset we may define) or do we just want a single fdri:DatasetSeries class which can optionally include all of the properties required to record metadata aggregated from series members?

Annotations

Annotations provide an extension point in the model where different kinds of annotation may be added to a catalogued resource.

The annotation property is defined as a complex observable property which allows for the ability to specify units of measurement etc.

An annotation can also be used to qualify a property value. For example when a measurement applies to some percentage of the observed entity, that percentage value can be captured as an annotation of the property value using the fdri:qualifier relation.

Annotations have: * an annotation property ( fdri:property ) which is a complex observable property drawn from a controlled list defined by the parent catalog of the annotated resource * either * an fdri:hasValue property whose value is a single fdri:PropertyValue providing the static value of the annotation or * an fdri:hasValueSeries property whose value is an fdri:PropertyValueSeries providing a series of values for the annotation that changes over time.

An fdri:Annotation can also be used as the value of an fdri:qualifier property on a fdri:PropertyValue or fdri:TimeBoundPropertyValue , to provide additional contextual qualification to a property value.

classDiagram class Resource["dcat:Resource"] class Annotation["fdri:Annotation"] class COP["iop:Variable"] class PropertyValue["fdri:PropertyValue"] { value: rdfs:Literal minValue: rdfs:Literal maxValue: rdfs:Literal valueReference: rdfs:Resource } class PropertyValueSeries["fdri:PropertyValueSeries"] class TBPV["fdri:TimeBoundPropertyValue"] class Period["dcat:PeriodOfTime"] Resource --> Annotation: fdri_hasAnnotation Annotation --> COP: fdri_property Annotation --> PropertyValue: fdri_hasValue Annotation --> PropertyValueSeries: fdri_hasValueSeries PropertyValueSeries --> TBPV: fdri_hasCurrentValue PropertyValueSeries --> TBPV: fdri_hadValue TBPV --> Period: fdri_interval TBPV --|> PropertyValue PropertyValue --> Annotation: fdri_qualifier

Observation Dataset Model

fdri:ObservationDataset is defined as a subclass of dcat:Dataset and is intended to represent the class of datasets providing environmental observations.

classDiagram class ObservationDataset["fdri:ObservationDataset"] class FoI["fdri:GeospatialFeatureOfInterest"] class EMF["fdri:EnvironmentalMonitoringFacility"] class EMP["fdri:EnvironmentalMonitoringProgramme"] class Variable["iop:Variable"] class Measure["fdri:Measure"] class ProcessingLevel["fdri:ProcessingLevel"] ObservationDataset --> FoI: sosa_hasFeatureOfInterest ObservationDataset --> Variable: sosa_observedProperty ObservationDataset --> Measure: fdri_measure ObservationDataset --> EMF: fdri_originatingFacility ObservationDataset --> EMP: fdri_originatingProgramme ObservationDataset --> ProcessingLevel: fdri_processingLevel

fdri:ObservationDataset has the following properties:

Time-Series Dataset Model

An fdri:TimeSeriesDataset is defined as a subclass of fdri:ObservationDataset with some additional properties to convey any statistical aggregation applied to the observations in the dataset.

classDiagram class TimeSeriesDataset["fdri:TimeSeriesDataset"] class TimeSeriesDefinition["fdri:TimeSeriesDefinition"] { fdri:sourceBucket: xsd:string fdri:sourceDataset: xsd:string fdri:sourceColumnName: xsd:string } class Plan["fdri:TimeSeriesPlan"] class ProcessingLevel["fdri:ProcessingLevel"] class Variable["iop:Variable"] class Measure["fdri:Measure"] TimeSeriesDefinition --> ProcessingLevel: fdri_processingLevel TimeSeriesDataset --> TimeSeriesDefinition: dct_type TimeSeriesDefinition --> Variable: sosa_observedProperty TimeSeriesDefinition --> Measure: fdri_measure TimeSeriesDefinition --> Plan: fdri_methodology Plan --> TimeSeriesDefinition: fdri_uses TimeSeriesDataset --> ProcessingLevel: fdri_processingLevel TimeSeriesDataset --> Variable: sosa_observedProperty TimeSeriesDataset --> Measure: fdri_measure

An fdri:TimeSeriesDataset represents a dataset that consists of a time-series of observations of a single variable by some fdri:EnvironmentalMonitoringFacility , the time series itself is soft-typed (using dct:type ) by an fdri:TimeSeriesDefinition , which in turn has the following properties:

NOTE The datasets for different sites are saved in separate folders within the same path structure within the bucket. This is expected to be the case for other projects processed through the DRI pipeline, and so site specific paths are not currently specified in the time series definition metadata.

Time-Series Dataset Versioning

For each time-series, there is a dataset resource representing the time-series (the "versioned dataset") and a separate resource for each version of the time-series (the "dataset version"). A new version is created whenever a new processing pipeline is applied to the raw data and each version of the time series will have a different DOI.

flowchart bunny-ta-1min bunny-ta-1min-20240815 bunny-ta-1min-20241017 bunny-ta-1min --hasVersion--> bunny-ta-1min-20240815 bunny-ta-1min --hasVersion--> bunny-ta-1min-20241017 bunny-ta-1min --hasCurrentVersion--> bunny-ta-1min-20241017 bunny-ta-1min-20241017 --replaces--> bunny-ta-1min-20240815

QUESTION Does this proposal align with the processing architecture? What context does a processing agent have when it processes the upstream dataset.

QUESTION What metadata is strictly consistent across versions? This might be metadata that is stated only on the versioned dataset and not restated on each dataset version.

QUESTION Are raw datasets treated as versioned datasets or just as a single unversioned dataset that is monotonically increasing in size?

QUESTION DCAT is relatively relaxed about version relationships and so we can have one TimeSeriesDataset as a version of another. However this could potentially get confusing and makes it slightly harder to filter a query to only return the top level versioned datasets (though these would be the only dataset resources with a hasCurrentVersion property on them). Should we consider adding TimeSeriesDatasetVersion to represent the dataset versions and introduce additional constraints so that a TimeSeriesDatasetVersion resource cannot itself have versions.

Time-Series Dataset Annotations

Annotations may be used to assert quality metrics about Time-Series Datasets. The values for these metrics may be qualified with a value giving the date range of observations that the annotation applies to (qualifier property http://fdri.ceh.ac.uk/ref/common/cop/observation-period ) to specify metrics that apply to a range of observations in the time-series. An annotation value that is not qualified with an observation period, is assumed to be providing a metric about the dataset as a whole.

The currently defined metrics annotation properties are:

Additional metrics annotation properties may be defined as needed. It is recommended that all such properties should be defined with an iop:hasObjectOfInterest property with the value fdri:TimeSeriesDataset if the metric specifically applies to time-series data.

Gridded Dataset Model

An fdri:GriddedDataset is an fdri:ObservationDataset which is distributed as multi-dimensional array data. Formats that use this approach include netCDF and ZARR. In addition to all of the standard metadata of an fdri:ObservationDataset , an fdri:GriddedDataset includes metadata about the structure of the multi-dimensional data.

Gridded Dataset Structure

An fdri:GriddedDataset contains: * zero or more fdri:GriddedContainer s * zero or more fdri:Dimension s, * zero or more fdri:Array s, and

An fdri:GriddedContainer is a nested structure which may itself contain fdri:Dimensions , fdri:Arrays and other fdri:GriddedContainer s.

An fdri:Dimension can be used to provide a common definition of the extent of a dimension which is shared by many fdri:Arrays . The size of the dimension can be specified as an integer value using the fdri:size property.

An fdri:Array represents one multi-dimensional array in the dataset. The property fdri:shape can be used to define the shape of an array as an RDF list of integer values giving the size of each dimension of the array. The property fdri:references can be used to reference the fdri:Dimension s and/or fdri:Array s that define each of the dimensions of this array.

An fdri:Array , fdri:Dimension or fdri:GriddedContainer may reference the fdri:Variable (s) it provides values for using the sosa:observedProperty property, or the fdri:Measure (s) it provides values for using the fdri:measure . All of these types also allow annotations to be referenced using fdri:hasAnnotation . Annotations are the recommended way to capture additional metadata that may be encoded in the dataset such as unit of meaure, coordinates, methods used etc.

--- config: class: hideEmptyMembersBox: true --- classDiagram class ObservationDataset["fdri:ObservationDataset"] class GriddedDataset["fdri:GriddedDataset"] class GriddedContainer["fdri:GriddedContainer"] class GriddedDatasetResource["fdri:GriddedDatasetResource"] class Dimension["fdri:Dimension"] { fdri:size: xsd:integer } class Array["fdri:Array"] { fdri:shape: List&lt;xsd:integer&gt; } class Annotation["fdri:Annotation"] class Variable["fdri:Variable"] class Measure["fdri:Measure"] ObservationDataset <|-- GriddedDataset GriddedDatasetResource <|-- GriddedContainer GriddedDatasetResource <|-- Dimension GriddedDatasetResource <|-- Array Array --> Dimension: fdri_references Array --> Array: fdri_references GriddedDataset --> GriddedDatasetResource: fdri_contains GriddedContainer --> GriddedDatasetResource: fdri_contains GriddedDatasetResource --> Annotation: fdri_hasAnnotation GriddedDatasetResource --> Variable: sosa_observedProperty GriddedDatasetResource --> Measure: fdri_measure

QUESTION The current modelling does not preserve the ordering of references from an Array to its members in the fdri:references property, but does preserve the ordering of the dimensions in the fdri:shape property. This has been done to keep the fdri:references relation simple and to avoid requiring rdf:List processing to access the references. If there are use-cases for preserving the order of references in the metadata store, then either the range of fdri:references should be changed, or a new order-preserving property (e.g. fdri:referenceList ?) should be introduced.

Provenance and Activity Model

The core model will use the PROV-O ontology to record details of activities, their inputs and their outputs. Activities related to datasets would include processes such as data ingestion, quality checking, quality improvement, statistical derivation and so on. Activities can also be related to other assets, e.g. the installation of an asset, the repair or replacement of an asset, the decomissioning of an asset and so on.

We recommend using unqualified provenance relationships and a simple taxonomy of activity types. For example the derivation of one dataset from another could be modelled as:

flowchart TB entity1([Dataset 1]) entity2([Dataset 2]) activity[Aggregation Activity] script[Aggregation Script] dailyMeanAggregation[Daily Mean Aggregation] plan[Aggregation Script Configuration] entity1 -.prov:wasDerviedFrom.-> entity2([Entity]) activity --dct:type--> dailyMeanAggregation activity --prov:used--> entity2 activity --prov:wasAssociatedWith--> script activity -- prov:startedAtTime --> x[2024-02-01T20:00:00Z] activity -- prov:endedAtTime --> y[2024-02-01T20:10:11Z] activity -- prov:hadPlan --> plan entity1 --prov:wasGeneratedBy--> activity

NOTE In situations where the ingest is streaming/near-realtime it might make sense to have an open-ended Derivation and Ingest Activity which are only ended when the stream is closed or the ingest software agent updated. If so then it might be worth adding a notion of a run log (timestamp and log pointer) structure that can be appended to an open activity for each run instance.

PROV-O extension properties

PROV-O defines entity to activity relations only for generation( prov:wasGeneratedBy ) and invalidation( prov:wasInvalidatedBy ). To model the case where an activity extends or otherwise modifies an existing dataset without creating a new dataset instance, we add fdri:wasModifiedBy as a subproperty of prov:wasInfluencedBy .

Model for Agents

The model for agents is deliberately kept simple and inherits from dcat:CatalogResource . By implication, the metadata catalog will track individual agents that are involved in activities that update catalog resources.

QUESTION The assumption made here is that the metadata store is required to track information for both software agents and people and organisations and that this will be done by treating all such agents as resources in the metadata catalog. Is this a valid assumption, or do we in fact only need to track software agents as catalog resources - in which case we can use prov:Person and prov:Organisation directly and don't need the fdri namespaced types.

classDiagram direction BT class ProvAgent["prov:Agent"] class Agent["fdri:Agent"] class SoftwareAgent["fdri:SoftwareAgent"] { fdri:repository xsd:anyURI fdri:repositoryPath xsd:string } class CatalogResource["dcat:Resource"] { dct:title: rdf:langString dct:description: rdf:langString dct:contactPoint: vcard:Kind dct:issued: xsd:dateTime dct:modified: xsd:dateTime dct:identifier: rdfs:Literal dct:version: rdfs:Literal adms:versionNotes: rdfs:Literal } class Person["fdri:Person"] class Organization["fdri:Organization"] SoftwareAgent --|> Agent Person --|> Agent Organization --|> Agent Agent --|> CatalogResource Agent --|> ProvAgent

Note that dcat:Resource already has a property ( dct:contactPoint ) which can be used to capture contact details for prov:Person and prov:Organization resources.

dcat:Resource also provides a dct:version property which can be used to capture the version of a software agent as well as dct:issued and dct:modified for tracking when a software release was made, and adms:versionNotes for capturing software release notes. We add the fdri:repository property to provide an explicit property for capturing a link to a version control repository.

If additional software agent metadata should be captured, this model could be extended but it should be noted that each additional piece of metadata will need to be reported through to the metadata system by the workflow system, and assuming an appropriate version control system is already in place for managing software versions and releases, we should not be seeking to replicate all of that metadata in the FDRI catalog.

Model for Software Agent Configuration

The configuration used by an agent for an activity is captured by the prov:hadPlan property on the activity resource. The modelling for software agent configurations is discussed in more detail in Data Processing Configurations .

Variables

A Variable is a "description of something observed or derived, minimally consisting of an ObjectOfInterest and its Property" (taken from the description of the I-Adopt ontology upon which this part of the modelling is based).

The purpose of the Variable is to provide a structured way to capture information about what observations are recorded in environmental datasetes and to attempt to provide some commonality in descriptions across multiple projects. By describing datasets in terms of the Variables that they provide measurements for, we can improve discoverability and help users more quickly locate related datasets within the FDRI catalog.

The description of a Variable consists of multiple facets. The property, object of interest, context, matrix and constraints. Only the property and object of interest facets are required.

--- config: class: hideEmptyMembersBox: true --- classDiagram class Variable["fdri:Variable"] class Entity["iop:Entity"] class Constraint["fdri:Constraint"] class Property["iop:Property"] Variable --> "1..1" Property : iop_hasProperty Variable --> "1..1" Entity: iop_hasObjectOfInterest Variable --> "0..n" Entity: iop_hasContextObject Variable --> "0..1" Entity: iop_hasMatrix Variable --> "0..n" Constraint: iop_hasConstraint Constraint --> "1..n" Entity: iop_constrains

Property

The Property facet represents the abstract characteristic of the object of interest that is measured by the Variable. Some examples:

These properties should be gathered into a shared reference vocabulary and where possible it is recommended to relate properties to QUDT QuantityKind instances.

ObjectOfInterest

The ObjectOfInterest facet represents the class of thing whose property is measured by the Variable. e.g.

With just Property and ObjectOfInterest we can construct simple Variables which share the same property facet, but differ in the object of interest:

block-beta columns 1 TA["Air Temperature"] block TAP["Property: Temperature"] TAO["ObjectOfInterest: Air"] end space TS["Soil Temperature"] block TSP["Property: Temperature"] TSO["ObjectOfInterest: Soil"] end

Equally we can construct simple Variables that share the same ObjectOfInterest but differ in the property observed:

block-beta columns 1 TA["Air Temperature"] block TAP["Property: Temperature"] TAO["ObjectOfInterest: Air"] end space TRH["Air Relative Humidity"] block TRHP["Property: Relative Humidity"] TRHO["ObjectOfInterest: Air"] end
Through this reuse of vocabulary terms it is possibel to create networks of related variables and to construct more complex shared vocabularies (of variables), from more simple building blocks (properties and objects of interest).

Context

The Context facet relates a Variable to concepts which provide additional background information regarding the object of interest.

[!TODO] Find an example of context from the COSMOS data

Matrix

Tne Matrix facet describes the thing within which the object of interest is contained. For example if a variable measures "Dissolved nitrate molar concentration in precipitation water", the object of interest is "nitrate" and the matrix is "precipitation".

Constraint

Constraints provide additional contextual information for the object of interest, matrix and/or context object facets. A constraint may apply to any one of these facets or to multiple facets.

Constraints are often used to specify more detail about the context in which a measurement is taken e.g. "20cm depth" (which may contextualise the object of interest of a variable)

Measures

The iAdopt framework provides a means of describing what is being observed by a dataset. However, this does not provide information about how the observations are recorded and treated in the dataset. The Measure class combines the observed property with information about the unit and statistical aggregation of the measures taken of the observed property.

--- config: class: hideEmptyMembersBox: true --- classDiagram class Measure["fdri:Measure"] { fdri:valueType: rdf:Resource [0..1] } class Variable["fdri:Variable"] class Aggregation["fdri:Aggregation"] { fdri:periodicity: xsd:duration fdri:resolution: xsd:duration } class Unit["fdri:Unit"] class Concept["skos:Concept"] Measure --> "1..1" Variable: fdri_variable Measure --> "1..1" Unit: fdri_hasUnit Measure --> "0..1" Aggregation: fdri_aggregation Aggregation --> "1..1" Concept: fdri_valueStatistic Concept <|-- Unit

Value Type

The fdri:valueType property relates a Measure to the datatype used for representing the measure values. The range of this property is open, but values for simple properties should be taken from the XML Schema datatypes (e.g. xsd:decimal ).

Variable

The fdri:hasVariable property relates a Measure to the Variable for which values are provided.

Unit

The fdri:hasUnit property relates a Measure to a concept that describes the units in which the measurement is expressed. Examples include:

Where a unit is specified, the unit name property SHOULD also be specified providing a default display string for rendering a value with its units.

It is strongly recommended to use a common vocabulary for expressing units. The QUDT unit vocabulary provides a wide range of units as a controlled vocabulary.

Aggregation

Where a measure is the result of the aggregation of multiple values over some time period, the fdri:aggregation property can be used to relate the Measure to an Aggregation which represents both how the input values are aggregated (using the fdri:valueStatistic property) to produce the recorded measurement, and the time period over which that aggregation is applied. Examples of value statistic concepts include:

The fdri:periodicity property specifies the time period between aggregate values being reported. The fdri:resolution property specifies the time period between the measurements that are aggregated over the period. e.g. if fdri:periodicity is PT5M and fdri:resolution is PT30S then values are read every 30 seconds, and aggregated to produce a single aggregate value every 5 minutes.

Specialisation and Variable Hierarchies

A Variable can have broader/narrower relations to other Variables which define more generic or more specialised variants of the Variable.

For example a generic "Air Temperature" variable might only have its Property and ObjectOfInterest facets defined, and have a specialisation of "Sonic Air Temperature" with a Context facet indicating the method by which the observation is made, which may itself have a specialisation "Sonic Air Temperature at 2m above sea level" with an additional Context facet indicating the height at which the reading is taken.

[!NOTE] It should be noted that even without the structure of a hierarchy, the faceted nature of Variables makes it relatively easy to discover specialisations and generalisations simply by comparing the facet values (e.g. all Temperature variables, all Air Temperature variables, all Sonic Air Temperature variables etc.).

Environmental Monitoring Facility Model

Programme, Network and Facility

Based on the INSPIRE Environmental Monitoring Facility Technical Guidelines framework , the catalog models reference information about infrastructure such as sites, stations, and drones using the fdri:EnvironmentalMonitoringFacility class.

An fdri:EnvironmentalMonitoringFacility may have:

Activities which affect the facility

An fdri:EnvironmentalMonitoringNetwork is a collection of fdri:EnvironmentalMonitoringFacility instances which are used for some common monitoring purpose.

An fdri:EnvironmentalMonitoringProgramme is a programme of work which makes use of one or more fdri:EnvironmentalMonitoringNetwork and/or fdri:EnvironmentalMonitoringFacility instances to deliver its outcomes.

Typically a dataset will be related to the fdri:EnvironmentalMonitoringProgramme under which the dataset was created as well as one or more fdri:EnvironmentalMonitoringFacility from which the data was sourced.

fdri:EnvironmentalMonitoringFacility is defined as a subclass of dcat:Resource , meaning it is an item with an entry in the catalog and so can be the subject of a dcat:CatalogRecord . The dcat:Resource class aslo defines a number of useful properties which can be used to capture many of the properties of an fdri:EnvironmentalMonitoringFacility such as title, description, modified date and themes (keywords). Although not shown here, the DCAT model also provides common relationships between resources which can be used such as dcterms:hasPart and dcterms:replaces , as well as dcterms:qualifiedRelation which could be used to capture any other more specialised forms of relation between facilities and other catalogued resourcers. Additional properties are defined to cover the proposed model for fdri:EnvironmentalMonitoringFacility in the external catalog, although it may be possible to exlude some of these from the detailed metadata catalog if the external catalog is the canonical record for these resources.

We use the sosa:observes property to record a relationship between an fdri:EnvironmentalMonitoringFacility and the iop:Variable (s) it observes. This would most likely only be defined at the level of fdri:EnvironmentalMonitoringSensor resources, and then aggregated through query to parent facilities to avoid the need to keep multiple resources in sync as new sensors are deployed or existing sensors removed from a site. In addition to sosa:observes it is also possible to use fdri:measures to record a relatioship between an fdri:EnvironmentalMonitoringFacility and the fdri:Measure (s) it makes. An fdri:Measure combines an variable with additional information about the unit of measure and any statistical aggregation applied. A facility may report multiple fdri:Measure s for the same fdri:Variable that it observes (e.g. an hourly mean, and a standard deviation).

Activities which affect a facility can be related to the fdri:EnvironmentalMonitoringFacility by using properties prov:wasGeneratedBy , prov:wasInvalidatedBy , and fdri:wasModifiedBy . prov:wasGeneratedBy should be reserved for commissioning / manufacturing activities. prov:wasInvalidatedBy should be reserved for decomissioning activities. fdri:wasModifiedBy should be used for all other activities which affect the facility (e.g. maintenance activities).

A number of organisations or individuals may be involved in some aspect of the commission and/or maintenance of a facility. The prov:qualifiedAttribution property can be used to relate an fdri:EnvironmentalMonitoringFacility to any number of fdri:RelatedPartyAttribution resources. Each fdri:RelatedPartyAttribution specifies an fdri:Agent ( prov:agent ) acting in a particular fdri:RelatedParyRole ( dcat:hadRole ).

classDiagram class Resource["dcat:Resource"] { dct:title? dct:description? dct:identifier? } class Programme["fdri:EnvironmentalMonitoringProgramme"] class Network["fdri:EnvironmentalMonitoringNetwork"] class Facility["fdri:EnvironmentalMonitoringFacility"]{ geos:hasGeometry: geos:Geometry geos:hasRepresentativePoint: geos:Geometry geos:hasCentroid: geos:Geometry? geos:hasBoundingBox: geos:Geometry? geo:lat: string? geo:long: string? spatialrelations:easting? spatialrelations:northing? fdri:isMobile: xsd:boolean? sosa:hasFeatureOfInterest: sosa:Feature* fdri:environmentalDomain: fdri:EnvironmentalDomain* } class RelatedParty["fdri:RelatedPartyAttribution"] class Agent["prov:Agent"] class AgentRole["fdri:RelatedPartyRole"] class PeriodOfTime["dct:PeriodOfTime"] { dcat:startDate xsd:date/xsd:dateTime dcat:endDate xsd:date/xsd:dateTime } class Concept["skos:Concept"] class FacilityType["fdri:EnvironmentalMonitoringFacilityType"] class Variable["iop:Variable"] class Activity["prov:Activity"] class Measure["fdri:Measure"] Resource <|-- Facility Programme --> Network: fdri_utilises Programme --> Facility: fdri_utilises Network --> Facility: fdri_contains Facility --> RelatedParty: prov_qualifiedAttribution RelatedParty --> AgentRole: dcat_hadRole RelatedParty --> Agent: prov_Agent Facility --> PeriodOfTime: fdri_operatingPeriod Facility --> FacilityType: dct_type FacilityType --|> Concept Facility --> Variable: sosa_observes Facility --> Measure: fdri_measures Facility --> Activity: fdri_wasModifiedBy Facility --> Activity: prov_wasGeneratedBy Facility --> Activity: prov_wasInvalidatedBy Facility --> Facility: dct_hasPart

Site, Platform, System and Sensor

The fdri:EnvironmentalMonitoringFacility class has several subclasses defined to aid in mapping to the SOSA/SSN concepts of Platform, System and Sensor. The diagram below shows the relationship between the FDRI types and the mapping (via subclass relationships) to the SOSA/SSN types.

classDiagram class Facility["fdri:EnvrionmentalMonitoringFacility"] class Site["fdri:EnvironmentalMonitoringSite"] class Platform["fdri:EnvironmentalMonitoringPlatform"] class System["fdri:EnvironmentalMonitoringSystem"] class Sensor["fdri:EnvironmentalMonitoringSensor"] class SosaPlatform["sosa:Platform"] class SosaSystem["sosa:System"] class SosaSensor["sosa:Sensor"] Facility <|-- Site Facility <|-- Platform Facility <|-- System System <|-- Sensor SosaSystem <|-- System SosaSensor <|-- Sensor SosaSystem <|-- SosaSensor Site --|> SosaPlatform Platform --|> SosaPlatform

EnvironmentalMonitoringFacilityType

fdri:EnvironmentalMonitoringFacilityType is used to represent a category of facility. Categories may include broad groups of facility (e.g. drone, weather station, flow monitoring station), as well as narrower ones (e.g. a specific model of sensor).

As fdri:EnvironmentalMonitoringFacilityType extends skos:Concept facility categories may be organised into a hierarchical taxonomy of terms with broader/narrower relationships between them. skos:prefLabel can be used to capture the preferred term to describe the category, and skos:altLabel can be used to capture alternate non-preferred labels for findability. In addition, dcat:keyword can be used to add short string "tags" to an fdri:EnvironmentalMonitoringFacilityType to support other search use-cases.

Where a given agent is related to all facilities of a given type (e.g. the manufacturer of a specific model of sensor), this can be represented using the prov:qualifiedAttribiton property with a value of an fdri:RelatedPartyAttribution which specifies both the agent and the role they play in relation to the category of facility.

classDiagram class EMFType["fdri:EnvironmentalMonitoringFacilityType"] { dcat_keyword: xsd:string [0..*] } class Concept["skos:Concept"] class RPA["fdri:RelatedPartyAttribution"] class Agent["prov:Agent"] class RPR["fdri:RelatedPartyRole"] Concept <|-- EMFType Concept <|-- RPR EMFType --> RPA: prov_qualifiedAttribution RPA --> Agent: prov_agent RPA --> RPR : dcat_hadRole Concept --> Concept: skos_broader/skos_narrower

EnvironmentalMonitoringSite

fdri:EnvironmentalMonitoringSite is used to represent a static geospatial location at which one or more pieces of monitoring infrastructure may be deployed. It is subclassed from fdri:EnvironmentalMonitoringFacility and so has all the same core metadata that is provided by that class, but it is also mapped through a subclass relationship to the sosa:Platform type from the SOSA/SSN vocabulary which means that it can be the host of a deployment of a sensor or system of sensors.

The property fdri:siteVariance can be used to capture textual notes about the ways in which the layout of a site varies from the standard layout that would be expected of a site of this type (as defined by the dct:type property).

The property fdri:altitude can be used to record the altitude of the site in metres above sea-level.

classDiagram class EMFacility["fdri:EnvironmentalMonitoringFacility"] class EMSite["fdri:EnvironmentalMonitoringSite"] { fdri:altitude: xsd:decimal fdri:siteVariance: rdf:langString } EMFacility <|-- EMSite

QUESTION Is site variance information available in a more structured form that makes it possible to relate the information to the sensor deployment? Does site variance information change over time?

QUESTION Should all measures such as altitude be expressed as a schema:PropertyValue value with units, or do we bake the assumed units into the ontology?

EnvironmentalMonitoringPlatform

fdri:EnvironmentalMonitoringPlatform is used to represent either static or mobile infrastructure on which sensors or systems of sensors may be deployed. Examples include a post in the ground at a site, or a UAV or drone. It is subclassed from fdri:EnvironmentalMonitoringFacility to inherit the core facility metadata, and mapped to sosa:Platform to allow it to be the host of deployments of sensors.

[!NOTE] By mapping both fdri:EnvironmentalMonitoringSite and fdri:EnvironmentalMonitoringPlatform to sosa:Platform , a deployment of a sensor can be registered at the site level without having to model the detail of the physical infrastructure at the site, but that the model still has the flexibility to represent more detailed information if it is available and if deemed desireable to do so.

EnvironmentalMonitoringSystem

An fdri:EnvironmentalMonitoringSystem is a device which measures properties in the environment. As already noted, an fdri:EnvironmentalMonitoringSystem may be deployed either to an fdri:EnvironmentalMonitoringPlatform or directly to an fdri:EnvironmentalMonitoringSite .

An fdri:EnvironmentalMonitoringSystem carries several other metadata properties as shown in the diagram below.

classDiagram class System["fdri:EnvironmentalMonitoringSystem"] { fdri:assetNumber: xsd:string fdri:certification: rdf:Resource fdri:configuration: fdri:ConfigurationValueSeries fdri:dateOfPurchase: xsd:date fdri:dateOfDisposal: xsd:date fdri:cailbrationDue: xsd:date / xsd:dateTime fdri:retirementDate: xsd:date fdri:serialNumber: xsd:string adms:status: fdri:SystemStatus } class SystemType["fdri:EnvironmentalMonitoringSystemType"] System --> System: sosa_hasSubsystem System --> SystemType: dct_type

EnvironmentalMonitoringSystemType

An fdri:EnvironmentalMonitoringSystemType defines a category of monitoring system. Such categories may be broad (e.g. a category of sensor), or narrow (e.g. a specific model of sensor). fdri:EnvironmentalMonitoringSystemType extends fdri:EnvironmentalMonitoringFacilityType and can have the same relationships to related parties such as manufacturers as outlined above.

The fdri:settleInPeriod property allows the capture of the typical length of time that a system of this type needs to be allowed to settle in position before readings should be taken.

The sosa:observes property can be used to relate the fdri:EnvironmentalMonitoringSystemType to any number of fdri:Variables that a system of this type is capable of observing. It is recommended that this property should be used only for those variables that the system in question can directly observe and to not include any variables that are observed by a sub-system.

classDiagram class System["fdri:EnvironmentalMonitoringSystem"] class EMFType["fdri:EnvironmentalMonitoringFacilityType"] class SystemType["fdri:EnvironmentalMonitoringSystemType"] { fdri_settleInPeriod: xsd:duration [0..1] } class Concept["skos:Concept"] class Variable["fdri:Variable"] System --> SystemType: dct_type SystemType --> Variable: sosa_observes SystemType --|> EMFType EMFType --|> Concept

EnvironmentalMonitoringSensor

An fdri:EnvironmentalMonitoringSensor is intended to represent an individual sensor and is subclassed from sosa:Sensor and may be deployed either to an fdri:EnvironmentalMonitoringPlatform or directly to an fdri:EnvironmentalMonitoringSite .

As fdri:EnvironmentalMonitoringSensor is subclassed from fdri:EnvironmentalMonitoringSystem it also inherits the additional metadata shown for that class and faults can be recorded against individual sensors.

Geo-Spatial Feature Of Interest

An fdri:EnvironmentalMonitoringFacility monitors some set of features of the environment. Where those features are spatially located, the class fdri:GeospatialFeatureOfInterest may be used to represent them.

classDiagram class Feature["sosa:Feature"] class GeoFeature["fdri:GeospatialFeatureOfInterest"] class GeoFeature { geos:hasGeometry: geos:Geometry geos:hasRepresentativePoint: geos:Geometry geos:hasCentroid: geos:Geometry? geos:hasBoundingBox: geos:Geometry? geo:lat: string? geo:long: string? spatialrelations:easting? spatialrelations:northing? } Feature <|-- GeoFeature

The properties of fdri:GeospatialFeatureOfInterest provide ways of describing the geo-spatial extent of the feature which are described in more detail in Notes on Geo-spatial Resources

As already shown, the GeospatialFeatureOfInterest may also be referenced from the Dataset which contains observations of that feature.

FacilityGroup

A FacilityGroup is an unordered collection of EnvironmentalMonitoringFacility instances that share some common feature. A FacilityGroup is treated as a Resource in the metadata catalog and so may have a title, provenance and publication information and so on.

The dct:identifier property can be used to capture the identifier(s) assigned to the group by a programme.

For simple groupings where there is no need to record historical membership or to provide a date range for a membership, the fdri:hasMember property can be used. For cases where membership of a group may change over time, the class fdri:FacilityGroupMembership can be used.

The dct:type property can be used to specify the nature of the grouping.

Where facility groupings are used to represent geospatial areas, there are optional properties to capture the geopatial extent of the grouping (e.g. the boundary of the region or catchment area that the group represents).

classDiagram class EMF["fdri:EMFacility"] class Resource["dcat:Resource"] { dct:title? dct:description? dct:identifier? } class FacilityGroup["fdri:FacilityGroup"] { geos:hasGeometry: geos:Geometry? geos:hasRepresentativePoint: geos:Geometry? geos:hasCentroid: geos:Geometry? geos:hasBoundingBox: geos:Geometry? geo:lat: string? geo:long: string? spatialrelations:easting? spatialrelations:northing? } class FacilityGroupMembership["fdri:FacilityGroupMembership"] class PeriodOfTime["dct:PeriodOfTime"] class Concept["skos:Concept"] class FacilityGroupType["fdri:FacilityGroupType"] Concept <|-- FacilityGroupType Resource <|-- FacilityGroup FacilityGroup --> EMF: fdri_hasMember FacilityGroupType <-- FacilityGroup: dct_type FacilityGroup <-- FacilityGroupMembership: fdri_group FacilityGroupMembership --> EMF: fdri_member FacilityGroupMembership --> PeriodOfTime: fdri_interval

Environmental Monitoring Activity Model

Environmental Monitoring Activity

The class fdri:EnvironmentalMonitoringActivity represents some activity which is used to gather observations about some feature of interest in the environment.

An fdri:EnvironmentalMonitoringActivity has the following properties:

An fdri:EnvironmentalMonitoringActivity may be initiated ( fdri:initiated ) by either an fdri:EnvironmentalMonitoringProgramme or by another fdri:EnvironmentalMonitoringActivity .

As fdri:EnvironmentalMonitoringActivity is a sub-class of prov:Activity it can also be related to entities that it generates or modifies ( prov:wasGeneratedBy , fdri:wasModifiedBy ). It is recommended that prov:wasGeneratedBy should be used only for those resources which are a direct result of the activity (e.g. a GPS track log for a UAV flight or a raw sensor log file). An fdri:EnvironmentalMonitoringActivity generates data which contributes to any number of fdri:ObservationDataset s. The property fdri:originatingActivity which should be used to relate an fdri:ObservationDataset to the fdri:EnvironmentalMonitoringActivity (or activities) which produced the data contained in the dataset.

--- config: class: hideEmptyMembersBox: true --- classDiagram direction LR class Activity["prov:Activity"] { startedAtTime: xsd:dateTime endedAtTime: xsd:dateTime } class EMActivity["fdri:EnvironmentalMonitoringActivity"] class EMProgramme["fdri:EnvironmentalMonitoringProgramme"] class ObservationDataset["fdri:ObservationDataset"] class Agent["prov:Agent"] class Variable["fdri:Variable"] class Measure["fdri:Measure"] class Association["fdri:RelatedPartyAssociation"] class Concept["skos:Concept"] class FacilityUsage["fdri:FacilityUsage"] class FoI["fdri:GeospatialFeatureOfInterest"] class ActivityType["fdri:ActivityType"] class Procedure["fdri:Procedure"] class RelatedPartyRole["fdri:RelatedPartyRole"] class EMFacility["fdri:EnvironmentalMonitoringFacility"] Activity <|-- EMActivity EMActivity --> EMActivity: fdri_initiated EMActivity --> ActivityType: dct_type EMProgramme --> EMActivity: fdri_initiated ObservationDataset --> EMActivity: fdri_originatingActivity EMActivity --> Variable: sosa_observes EMActivity --> Measure: fdri_measures EMActivity --> FoI: sosa_hasFeatureOfInterest EMActivity --> Association: prov_qualifiedAssociation Association --> Agent: prov_agent Association --> Procedure: prov_hadPlan Association --> RelatedPartyRole: prov_hadRole EMActivity --> FacilityUsage: fdri_facilityUsage FacilityUsage --> EMFacility: prov_used FacilityUsage --> FacilityUsageRole: prov_hadRole FacilityUsageRole --|> Concept RelatedPartyRole --|> Concept

Example: UAV dataset using Environmental Monitoring Activities

As an example of the use of fdri:EnvironmentalMonitoringActivity , take the case of a dataset derived from a survey performed using a drone. The drone is piloted over a site, taking readings of the concentration of nitrogen oxide (NOx) in the atmosphere. The survey consists of multiple individual sorties, and the data from each of the sorties is then combined into a single dataset.

Survey and Sorties as nested activities

Both the survey, and each sortie in the survey can be modelled as an fdri:EnvironmentalMonitoringActivity . With the sortie activities being intiated by the survey activity, and the survey activity being initiated by the fdri:EnvironmentalMonitoringProgramme that the survey is part of.

flowchart Programme["Programme &lt;&lt;fdri:EnvironmentalMonitoringProgramme>>"] Survey["Survey &lt;&lt;fdri:EnvironmentalMonitoringActivity>> startedAtTime: 2025-06-21T09:00:00Z endedAtTime: 2025-06-21T11:00:00Z"] Flight1["Flight 1 &lt;&lt;fdri:EnvironmentalMonitoringActivity>> startedAtTime: 2025-06-21T09:15:00Z endedAtTime: 2025-06-21T09:45:00Z"] Flight2["Flight 2 &lt;&lt;fdri:EnvironmentalMonitoringActivity>> startedAtTime: 2025-06-21T10:15:00Z endedAtTime: 2025-06-21T10:45:00Z"] Programme -- fdri:initiated --> Survey Survey -- fdri:initiated --> Flight1 Survey -- fdri:initiated --> Flight2

Site of the survey

The site over which the sorties are flown can be modelled as the feature of interest of the activities. In this case the sorties treated as having the same feature of interest as the survey and so the relationship does not need to be repeated.

As the site is an fdri:GeospatialFeatureOfInterest it can have geospatial co-ordinates and/or boundaries associated with it to locate the survey in geospatial terms. In this case only the latitude and longitude of a representative point for the survey site is given.

NOTE: This is a very simple example of providing geospatial information for an activity. In more detailed modelling it would be possible to use sosa:hasFeatureOfInterest to denote the geometry of each individual sortie as well as the bounding geometry of all sorties at the survey level.

flowchart Survey["Survey &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] Site["SOME_SITE &lt;&lt;fdri:GeospatialFeatureOfInterest>> geo:lat: 51.48199 geo:long: -2.76973"] Survey -- sosa:hasFeatureOfInterest --> Site

Platform and Sensor Usage

The drone used in the survey is an fdri:EnvironmentalMonitoringPlatform and it plays the role of Piloted Craft .

There is an fdri:Deployment of the sensor to the drone for the duration of the survey. In some cases a sensor or package of sensors may be more permanently affixed to a craft, in which case the time span for the fdri:Deployment may be much broader than the time span of any fdri:EnvironmentalMonitoringActivity that makes use of the drone.

As the same drone is used for the same purpose in each survey, the metadata about the use of the drone can be captured at the survey level.

flowchart Survey["Survey &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] Drone["Drone 123 &lt;lt;fdri:EnvironmentalMonitoringPlatform"] DroneModel["Some Make/Model"] Quadcopter["Quadcopter"] Sensor["NOx Sensor #345 &lt;&lt;EMSensor>>"] SensorModel["Some Make / Model"] SensorType["NOx Detector"] Variable["NOx Concentration &lt;&lt;Variable>>"] Deployment["NOx Sensor Deployment &lt;&lt;Deployment>> startedAtTime: 2025-06-21T09:00:00Z endedAtTime: 2025-06-21T11:00:00Z"] FacilityUsage["Use of Drone 123 in Survey &lt;&lt;fdri:FacilityUsage>>"] Craft["Piloted Craft &lt;&lt;fdri:FacilityUsageRole>>"] DroneModel -- skos:broader --> Quadcopter Drone -- dct:type --> DroneModel Sensor -- sosa:observedProperty --> Variable Sensor -- dct:type --> SensorModel SensorModel -- skos:broader --> SensorType Deployment -- ssn:deployedOnPlatform --> Drone Deployment -- ssn:deployedSystem --> Sensor Survey -- fdri:facilityUsage --> FacilityUsage FacilityUsage -- prov:entity --> Drone FacilityUsage -- prov:hadRole --> Craft

Piloting of the drone

The pilot of the drone is an fdri:Agent who follows an fdri:Procedure in the execution of each sortie. In this case the procedure used relates to the piloting of the craft on a single sortie and so the relationship is expressed against each of the sortie activities as an fdri:RelatedPartyAssociation .

flowchart Flight1["Flight 1 &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] Flight2["Flight 2 &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] Piloting["Piloting of Sortie &lt;&lt;fdri:RelatedPartyAssociation>>"] JohnSmith["John Smith &lt;&lt;fdri:Agent>>"] Pilot["Pilot &lt;&lt;fdri:RelatedPartyRole>>"] SortieProcedure["Sortie Procedure &lt;&lt;fdri:Procedure>>"] Flight1 -- prov:qualifiedAssociation --> Piloting Flight2 -- prov:qualifiedAssociation --> Piloting Piloting -- prov:agent --> JohnSmith Piloting -- prov:hadPlan --> SortieProcedure Piloting -- prov:hadRole --> Pilot

Outputs generated by each sortie

A raw flight log is produced for each sortie. These are the directly generated data files which are then processed in conjunction with the sensor logs to produce the dataset. These files could be modelled as prov:wasGeneratedBy each sortie.

NOTE This optional modelling of the outputs of each sortie does not preclude the option of creating full-blown fdri:ObservationDatasets from each sortie and relating them to the sortie activity that the data came from.

flowchart Flight1["Flight 1 &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] Flight2["Flight 2 &lt;&lt;fdri:EnvironmentalMonitoringActivity>>"] FlightLog1["Flight Log - Flight 1 &lt;&lt;Dataset>>"] FlightLog1 -- dct:type --> FlightLog FlightLog1 -- prov:wasGeneratedBy --> Flight1 FlightLog2["Flight Log - Flight 1 &lt;&lt;Dataset>>"] FlightLog2 -- dct:type --> FlightLog FlightLog2 -- prov:wasGeneratedBy --> Flight2

Dataset created from the survey

The survey data is compiled into a gridded dataset. The metadata for this dataset uses fdri:originatingActivity to reference the survey activity, fdri:originatingFacility to reference the drone used in the survey, and sosa:observes to reference the variable measured.

flowchart Dataset["UAV Sensor Dataset &lt;&lt;GriddedDataset>>"] Variable["NOx Concentration &lt;&lt;Variable>>"] UAV["Drone #123 &lt;&lt;EnvironmentalMonitoringFacility>>"] UAVModel["Some Make/Model"] Quadcopter["Quadcopter"] Survey["Survey &lt;&lt;EnvironmentalMonitoringActivity>>"] UAVModel -- skos:broader --> Quadcopter UAV -- dct:type --> UAVModel Dataset -- originatingActivity --> Survey Dataset -- originatingFacility --> UAV Dataset -- sosa:observedProperty --> Variable

Deployments

Deployments are used when a system (a sensor or package of sensors) is deployed in the field.

Deployments are modelled as a sub-class of prov:Activity and of ssn:Deployment .

A Deployment may have:

classDiagram direction TB class EMPlatform["fdri:EnvironmentalMonitoringPlatform"] class EMSystem["fdri:EnvironmentalMonitoringSystem"] class EMSite["fdri:EnvironmentalMonitoringSite"] class Activity["prov:Activity"] { prov:startedAtTime: xsd:dateTime [0..1] prov:endedAtTime: xsd:dateTime [0..1] } class Deployment["ssn:Deployment"] class EMDeployment["fdri:Deployment"] class EMDeployment { fdri:canopyHeight: xsd:decimal [0..1] fdri:settleInPeriod: xsd:duration [0..1] fdri:dependencyNote: rdf:langString [0..*] fdri:deploymentNote: rdf:langString [0..*] fdri:deploymentVariance: rdf:langString[0..*] } class Procedure["fdri:Procedure"] Activity <|-- Deployment Deployment <|-- EMDeployment EMDeployment --> EMPlatform: ssn_deployedOnPlatform EMDeployment --> EMSite: ssn_deployedOnPlatform EMDeployment --> EMSystem: ssn_deployedSystem EMDeployment --> Procedure: ssn_implements EMPlatform --> EMSite: fdri_atSite

TODO Clarify the notion of relative site location of sensors. Are individual sensors that are all attached to the same station positioned at different locations (and are those positions recorded?) When a station / sensor is given a relative location, exactly what is that relative to? Do we need to require an "origin" property for EnvironmentalMonitoringSite and/or EnvironmentalMonitoringStation (or indeed just on any EnvironmentalMonitoringFacility )?

QUESTION Are deployments equivalent to EMF Activities? If so, do we want to include that notion in the model at all?

Static Deployments

The class fdri:StaticDeployment is used to represent the deployment of a sensor or a package of sensors to a static platform such as a weather station at a monitoring site. The class carries additional properties deployedHeight and deployedDepth to capture the height above or below the ground where the sensor or sensor package was deployed.

The precise location of a static deployment may be captured either as an absolute location encapsulated as a geos:Feature resource, or as a location relative to an origin point defined by the fdri:EnvironmentalMonitoringPlatform that the deployment is on.

classDiagram class Deployment["fdri:Deployment"] { fdri:deploymentVariance: xsd_string } class StaticDeployment["fdri:StaticDeployment"] { fdri:deployedHeight: xsd_decimal fdri:deployedDepth: xsd_decimal fdri:deploymentPosition: xsd_string } class RelativeLocation["fdri:RelativeLocation"] { fdri:offsetNorth: xsd:decimal fdri:offsetEast: xsd:decimal fdri:elevation: xsd:decimal } class Feature["geos:Feature"] { geos:hasGeometry: geos:Geometry } Deployment <|-- StaticDeployment StaticDeployment --> RelativeLocation: prov_atLocation StaticDeployment --> Feature: prov_atLocation

Mobile Deployments

The class fdri:MobileDeployment is used to capture the deployment of a system to a mobile platform such as a boat or a drone. In such cases, each sortie of mobile platform with the deployed system should be recorded as a separate fdri:MobileDeployment (e.g. when multiple flights are made by a drone with a particular package of sensors).

The fdri:trackLog property should be used to reference the detailed (possibly timed) track of the sortie, but the properties geos:hasGeometry , geos:hasRepresentativePoint , geos:hasCentroid , geos:hasBoundingBox , geo:lat , geo:long , spatialrelations:easting and spatialrelations:northing are also provided to allow the representative point location, geospatial path or the area extent of the track to be captured in a form suitable for display and/or geo-spatial query. For notes on these additional properties please refer to Notes on Geo-spatial Resources .

classDiagram class Deployment["fdri:Deployment"] class MobileDeployment["fdri:MobileDeployment"] class MobileDeployment { fdri:trackLog: Resource geos:hasGeometry: geos:Geometry geos:hasRepresentativePoint: geos:Geometry geos:hasCentroid: geos:Geometry? geos:hasBoundingBox: geos:Geometry? geo:lat: string? geo:long: string? spatialrelations:easting? spatialrelations:northing? } Deployment <|-- MobileDeployment

QUESTION Should the range of trackLog be more specialised? The assumption is that we don't want to try and model a flight path, but just reference it. If we are just referencing a resource do we want to use the DCAT Distribution class to capture information about the track log such as its format and size?

Sensor / System Model

This area of the model is concerned with defining sensor packages, models of sensor used and related procedures as well as the relationship to deployed instances of specific packages/sensors.

classDiagram class Sensor["fdri:EnvironmentalMonitoringSensor"] class EMSystem["fdri:EnvironmentalMonitoringSystem"] { fdri:serialNumber: string } class SystemType["fdri:EnvironmentalMonitoringSystemType"] class ObservableProperty["sosa:ObservableProperty"] EMSystem --> SystemType: dct_type SystemType --> ObservableProperty: sosa_observes EMSystem --> ObservableProperty: sosa_observes EMSystem --> EMSystem: ssn_hasSubsystem Sensor --|> EMSystem

EnvironmentalMonitoringSystemType is intended to be used to capture specific pre-defined packages of sensors or sub-systems. e.g. FDRI Weather Station Sensor Package , FRDI Precipitation Station Sensor Package , as well as specific models of Sensor e.g. TFA 30-3121 Temperature Sensor . The dct:hasPart relation is used to construct part-whole relations between a system/package and its components. Although not shown in this diagram, fdri:EnvironmentalMonitoringSystemType is defined as a subclass of skos:Concept .

fdri:EnvironmentalMonitoringSensor is intended to capture a specific physical instance of some type of sensor. It is defined to extend sosa:Sensor .

fdri:EnvironmentalMonitoringSystem is intended to capture packages of multiple sensors.

The dct:type relation relates a fdri:EnvironmentalMonitoringSensor or fdri:EnvironmentalMonitoringSystem to the fdri:EnvironmentalMonitoringSystemType that represents the package build or sensor model.

An fdri:EnvironmentalMonitoringSystemType represents a model of sensor, or a package of specific models of sensor. It can be related to the observable property/ies it provides measurements for using the sosa:observes property.

Sensor / System Procedures

classDiagram class SystemType["fdri:EnvironmentalMonitoringSystemType"] class ProcedureType["fdri:ProcedureType"] class Procedure["fdri:Procedure"] { fdri:procedurePeriodicity: xsd:duration } class Resource["dcat:Resource"] class Concept["skos:Concept"] class Plan["prov:Plan"] Plan <|-- Procedure Resource <|-- Procedure Procedure <-- SystemType : fdri_hasProcedure Procedure --> ProcedureType: dct_type ProcedureType --|> Concept SystemType --|> Concept

fdri:ProcedureType is intended to capture categories of procedure, e.g. Installation Procedure , Calibration Procedure etc. The class fdri:Procedure is used to represent the procedure that applies to a specific system. fdri:Procedure is defined as a subclass of prov:Plan , enabling it to be used in relation to prov:Activity instances that represent the installation or calibration of a sensor or pacage of sensors. The class is also defined as a subclass of dcat:CatalogResource allowing all procedures to be recorded in a procedures catalog, The property procedurePeriodicity may be used to capture the recommended/required period between applications of the procedure to a given sensor.

Sensor / System Faults

A record of a system fault relates the affected EnvironmentalMonitoringFacility to one or more parameters which are affected by the fault.

A fault is a time-bounded event and so has a related interval with start and end date/date-times. The range of dcat:startDate and dcat:endDate is specified in DCAT as one of the following XSD datatypes xsd:gYear , xsd:gYearMonth , xsd:date , or xsd:dateTime .

The fault is understood as affecting all observations of the specified Variable made by the system during the specified interval. Multiple Variable instances may be specified on a single fault.

The removeData flag is set to true to indicate that affected observations should be removed from the data.

classDiagram class EMF["fdri:EnvironmentalMonitoringFacility"] class COP["iop:Variable"] class Fault["fdri:Fault"] class Fault { fdri:removeData: xsd:boolean rdfs:comment: xsd:string } class Period["dct:PeriodOfTime"] class Period { dcat:startDate: rdfs:Literal dcat:endDate: rdfs:Literal } Fault --> EMF: fdri_affectedFacility Fault --> COP: fdri_affectedVariable Fault --> Period: fdri_interval

Sensor Configuration

Each configuration property of a sensor is represented as a collection of time-bounded property values.

The dct:type property is used to relate a ConfigurationValueSeries to a skos:Concept that speficies the configured sensor property. This approach uses a taxonomy of configuration properties to capture the different ways in which a sensor could be configured which may provide greater flexibility in adapting the model to new sensor types with novel configuration properties than an approach based on using semantic relationships defined in the domain model.

The fdri:hasValue property relates the ConfigurationValueSeries to a collection of TimeBoundValueProperty instances representing the different values of the configured property through time (excluding the current value).

The fdri:hasCurrentValue property relates the fdri:ConfigurationValueSeries to the fdri:TimeBoundPropertyValue that represents the configuration value that currently applies to the sensor.

On each fdri:TimeBoundPropertyValue , the fdri:interval property specifies the period over which the configuration applies and the fdri:value property specifies the configuration value applied. By inheriting fdri:TimeBoundPropertyValue from schema:PropertyValues we can support single values, value ranges and references to other resources as the value of a configuration.

An ordering of fdri:TimeBoundPropertyValue instances could additionally be modelled using the dct:replaces relationship with each value referencing its immediate predecssor.

NOTE The preceding is based on the assumption that there is a need for the metadata store to retain historical configuration information. If there are no motivating use cases for this then the structure could be significantly simplified.

classDiagram class EMSystem["fdri:EnvironmentalMonitoringSystem"] class Configuration["fdri:TimeBoundPropertyValue"] class ConfigurationValueSeries["fdri:ConfigurationValueSeries"] class PeriodOfTime["dct:PeriodOfTime"] { dcat:startDate: xsd:date/xsd:dateTime dcat:endDate: xsd:date/xsd:dateTime } class ConfigurationProperty["fdri:ConfigurationProperty"] class Concept["skos:Concept"] class PropertyValue["schema:PropertyValue"] { schema:minValue: rdfs:Literal schema:maxValue: rdfs:Literal schema:value: rdfs:Literal schema:valueReference: rdf:Resource } EMSystem --> ConfigurationValueSeries: fdri_configuration ConfigurationValueSeries --> Configuration: fdri_hadValue ConfigurationValueSeries --> Configuration: fdri_hasCurrentValue ConfigurationValueSeries --> ConfigurationProperty: dct_type ConfigurationProperty --|> Concept Configuration --|> PropertyValue Configuration --> Configuration: dct_replaces Configuration --> PeriodOfTime: fdri_interval

TODO If we decide that the different time-bound property series of an EnvironmentalMonitoringSite can be captured in a soft-typed property value type, then reuse that type here rather than introduce ConfigurationValue

The diagram below shows how this structure can be used to capture the use of a specific version of firmware on a sensor with the firmware version identified by use of a URI

flowchart Sensor123 --fdri:configuration--> FIS FIS("Firmware Installation Configuration Series") --dct:type--> FirmwareInstallation FIS --fdri:hadValue--> F1 FIS --fdri:hadValue--> F2 FIS --fdri:hasCurrentValue--> F1 F1("Latest Value") --schema:valueReference--> http:/fdri.ceh.ac.uk/id/firmware-version/some-model/v2 F1 --fdri:interval --> int1("`dcat:startDate:...`") F2 --schema:valueReference--> http:/fdri.ceh.ac.uk/id/firmware-version/some-model/v1 F2("Previous Value") --fdri:interval --> int2("`dcat:startDate:... dcat:endDate:...`") F1 --dct:replaces--> F2

The same configuration value could also be captured as a string value if there is no registry of firmware versions that an identifier could resolve to:

flowchart Sensor123 --fdri:configuration--> FIS FIS("Firmware Installation Configuration Series") --dct:type--> FirmwareInstallation FIS --fdri:hadValue--> F1 FIS --fdri:hadValue--> F2 FIS --fdri:hasCurrentValue--> F1 F1("`Latest Value schema:value 'v1'`") --fdri:interval --> int1("`dcat:startDate:...`") F2("`Previous Value schema:value 'v2'`") --fdri:interval --> int2("`dcat:startDate:... dcat:endDate:...`") F1 --dct:replaces--> F2

Sensor Metadata

Metadata relating to a physical instance of a sensor can be modelled as properties of the fdri:EnvironmentalMonitoringSensor instance.

classDiagram class System["fdri:EnvironmentalMonitoringSensor"] class System { rdfs:label: rdf:LangString dct:description: rdf:LangString fdri:serialNumber: xsd:string fdri:assetNumber: xsd:string fdri:dateOfPurchase: xsd:date fdri:dateOfDisposal: xsd:date fdri:storageLocation: xsd:string fdri:certification: rdf:Resource fdri:serviceContactDetails: vcard:Kind rdfs:comment: rdf:LangString } class SensorStatus["fdri:SensorStatus"] class Concept["skos:Concept"] System --> SensorStatus : fdri_status SensorStatus --|> Concept

QUESTION Should any/all of this metadata appear on EnvironmentalMonitoringSystem ?

QUESTION Would we prefer the flexibility of soft-typed property values here rather than modelling a set of direct properties?

QUESTION Should any of these properties be captured as value series to track historical changes?

Sensor Deployment

Deployment history can be constructed from the SOSA model, by following ssn:deployedSystem back from the System to the Deployment(s) the system had. Such a traversal may also follow ssn:hasSubsystem relations to include deployments in which the system in question was one part of a larger package.

Sensor Maintenance Activities

Interventions made on a sensor, such as callibration or repair can be modelled as PROV-O activities which can also be used to capture information such as the individual or organisation undertaking the procedure.

flowchart activity["`prov:Activity Callibration of sensor #1234 on 2024-02-08`"] sensor["`fdri:EMSensor Sensor #1234`"] agent["`foaf:Agent Bob Smith`"] callibration["`fdri:ActivityType Sensor Callibration`"] activity -- prov:startedAtTime --> x[2024-08-01T10:00:00Z] activity -- prov:endedAtTime --> y[2024-02-08T10:30:11Z] activity -- prov:used --> sensor activity -- prov:wasAssociatedWith --> agent activity -- dct:type --> callibration

NOTE If there is more of a one to many relationship between recorded activities and the interventions on systems/sensors (e.g. a single site visit by an engineer results in the callibration of 6 sensors, the cleaning of 2 and the replacement of 2 others), then this might be better modelled using the full qualified version of PROV-O, possibly with a custom subclass of prov:Activity for maintenance

QUESTION Replace prov:used with a more meaningful relationship such as affected or appliedTo to relate the activity to the system affected by the activity.

Sensor Calibration Factors

In the FDRI model, a sensor calibration factor is modelled as a InternalDataProcessingConfiguration which applies to a combination of an EnvironmentalMonitoringSensor and one or more Variable s. When a sensor is calibrated, a new ConfigurationItem is added to the InternalDataProcessingConfiguration as the current configuration item and any previous value is retained using the hadConfigurationItem relationship.

The prov:wasGeneratedBy relation can also be applied to relate a calibration ConfigurationItem to the maintainance Activity that represents the sensor calibration.

An initial calibration performed by the manufacturer can also be recorded as an activity based on the information provided on the calibration certificate received.

flowchart sensor["`fdri:EMSensor Sensor #1234`"] variable["`iop:Variable SWIN`"] type["`skos:Concept Calibration Configuration`"] calibconfig["`fdri:InternalDataProcessingConfiguration Calibration configuration for sensor #1234`"] subgraph "Initial Calibration" calib1["`prov:Activity Manufacturer's callibration of sensor #1234 on 2020-01-05`"] calibconfig1["`fdri:ConfigurationItem Calibration value from 2020-01-05`"] calib1interval["`dcterms:PeriodOfTime startDate: 2020-01-05T00:00:00Z endDate: 2024-08-01T12:30:00Z`"] calibconfig1 -- fdri:observationInterval --> calib1interval calibconfig1 -- fdri:argument --> calibarg1 calibarg1["`fdri:ConfigurationArgument Correction Factor Argument #1`"] calibval1["`schema:PropertyValue schema:value 0.923`"] calibarg1 -- fdri:hasValue --> calibval1 end subgraph "Field Recalibration" calib2["`prov:Activity Field callibration of sensor #1234 on 2024-08-01`"] calibconfig2["`fdri:ConfigurationItem Calibration value from 2024-08-01`"] calib2interval["`dcterms:PeriodOfTime startDate: 2024-08-01T12:30:00Z`"] calibconfig2 -- fdri:observationInterval --> calib2interval calibarg2["`fdri:ConfigurationArgument Correction Factor Argument #2`"] calibconfig2 -- fdri:argument --> calibarg2 calibval2["`schema:PropertyValue schema:value 0.935`"] calibarg2 -- fdri:hasValue --> calibval2 end calibconfig -- fdri:hadConfigurationItem --> calibconfig1 calibconfig -- fdri:hasCurrentConfigurationItem --> calibconfig2 calibconfig -- fdri:appliesToSystem --> sensor calibconfig -- fdri:appliesToVariable --> variable calibconfig --> dcterms:type --> type calib1 -- prov:used --> sensor calib2 -- prov:used --> sensor calibconfig1 -- prov:wasGeneratedBy --> calib1 calibconfig2 -- prov:wasGeneratedBy --> calib2 scalar["`fdri:DataProcessingMethod Scalar correction`"] calibconfig1 -- fdri:method --> scalar calibconfig2 -- fdri:method --> scalar

System Capabilities and Ranges

The FDRI data model extends the SOSA/SSN System Capabilities Module to provide a way to capture information about the range of conditions under which a sensor can be operational, and to associate sensor-related operational properties such as sensitivity, accurracy and frequency with those operational ranges. Typically this model will be used to record the manufacturer's specification of the operational properties of a make/model of sensor under a manufacturer-defined "normal" operating condition.

classDiagram direction LR class EMSystemType["fdri:EnvironmentalMonitoringSystemType"] class Variable["fdri:Variable"] class Condition["fdri:Condition"] class SystemCapability["fdri:SystemCapability"] class OperatingRange["fdri:OperatingRange"] class SurvivalRange["fdri:SurvivalRange"] EMSystemType --> "0..*" SystemCapability: sys_hasSystemCapability EMSystemType --> "0..*" SurvivalRange: sys_hasSurvivalRange EMSystemType --> "0..*" OperatingRange: sys_hasOperatingRange SystemCapability --> "1" Variable: ssn_forProperty SystemCapability --> "0..*" Condition: sys_inCondition OperatingRange --> "0..*" Condition: sys_inCondition SurvivalRange --> "0..*" Condition: sys_inCondition

Conditions

Conditions define constraints on the environment in which a sensor operates and are used to set out the environmental conditions under which a given fdri:SystemCapability , fdri:SurvivalRange or fdri:OperatingRange apply.

An fdri:Condition has the following properties:

classDiagram class Condition["fdri:Condition"] { schema:minValue: rdfs:Literal schema:maxValue: rdfs:Literal schema:value: rdfsLiteral } class Unit["fdri:Unit"] class Variable["fdri:Variable"] Condition --> Variable: fdri_property Condition --> Unit: fdri_unit

For example, a condition of an air temperature between -40°C and +80°C can be represented as shown in the diagram below:

flowchart taCond["Condition: Air Temperature -40 to +80 degrees C"] ta["Air Temperature"] degc["Degrees Celsius"] taCond --property--> ta taCond --minValue--> taMin["-40.0"] taCond --maxValue--> taMax["80.0"] taCond --unit--> degc

System Capability

A sys:SystemCapability provides a specification of the capability of a system to perform its primary purpose. For sensors, this primary purpose is the observation of some fdri:Variable .

A sys:SystemCapability may be associated with either an fdri:EnvironmentalMonintoringSystemType , or with an fdri:EnvironmentalMonintorigSystem using the property sys:hasSystemCapability . In the former case, the capabilities are interpreted as applying to all systems of that type, and in the latter case as applying only to that specific system instance.

sys:SystemCapability has the following properties:

An fdri:SystemProperty provides the value of one capability characteristics. It has the following properties:

classDiagram class SystemCapability["sys:SystemCapability"] class Variable["fdri:Variable"] class SystemProperty["fdri:SystemProperty"] { minValue: rdfs:Literal maxValue: rdfs:Literal value: rdfs:Literal } class Condition["sys:Condition"] class Unit["fdri:Unit"] SystemCapability "0..*" --> "1" Variable: ssn_forProperty SystemCapability "0..*" --> "0..*" Condition: sys_inCondition SystemCapability "0..*" --> "1..*" SystemProperty: sys_hasSystemProperty SystemProperty "0..*" --> "1" Variable: fdri_property SystemProperty "0..*" --> "1" Unit: fdri_unit

The example below shows an imagined air temperature sensor and its capability. In this example the sensor under its normal operating range has an accuracy of +/- 0.5 degrees celsius, and a sensitivity of 0.1 degrees celsius.

flowchart ta["`Air Temperature &lt;&lt;fdri:Variable&gt;&gt;`"] taOp["`Temperature -40 to +80 &lt;&lt;fdri:Condition&gt;&gt;`"] taAcc["`TempMaster Accurracy &lt;&lt;fdri:SystemProperty&gt;&gt;`"] taSen["`TempMaster Sensitivity &lt;&lt;fdri:SystemProperty&gt;&gt;`"] acc["`Accuracy &lt;&lt;fdri:Variable&gt;&gt;`"] sen["`Sensitivity &lt;&lt;fdri:Variable&gt;&gt;`"] degc["`Degree Celsius &lt;&lt;fdri:Unit&gt;&gt;`"] taSensor["`TempMaster &lt;&lt;fdri:EMSystemType&gt;&gt;`"] --hasSystemCapability--> taCap taCap["`Temp Master Capability &lt;&lt;fdri:SystemCapability&gt;&gt;`"] --forProperty--> ta taCap --inCondition--> taOp taCap --hasSystemProperty--> taAcc taCap --hasSystemProperty--> taSen taAcc --property--> acc taAcc --minValue--> taAccMin["-0.5"] taAcc --maxValue--> taAccMax["+0.5"] taAcc --unit--> degc taSen --property--> sen taSen --value--> taSenVal["0.1"] taSen --unit--> degc taOp --minValue--> taOpMin["-40"] taOp --maxValue--> taOpMax["80"] taOp --unit--> degc

Capturing Sensor Error Codes as System Capability

The fdri:SystemCapability structure can also be used to capture the value(s) that a sensor reports under error conditions. By using a property representing the concept of an error value, and either a value range or a single value depending on how errors are reported.

fdri:Condition s may be attached to contextualize the conditions under which the error code is reported if this is known.

NOTE This capability is not intended to capture the separate error flags channel that some sensor systems provide, but only to capture the case where the measure channel can report an error value rather than a normal reading.

TODO Define the vocabulary for System Capability properties and include the IRI for the error code property here.

For example, if our fictional sensor is in an error state it will report a value of -9999. As this value is not a temperature reading, we encode it as a unitless value. This value may be reported under any condition and so no fdri:Condition is attached to the fdri:SystemCapability . For this reason this capability is recorded separately from details such as the accuracy and sensitivity of the sensor, which are values that apply only under normal operating conditions. This can be represented as shown in the diagram below.

flowchart ta["`Air Temperature &lt;&lt;fdri:Variable&gt;&gt;`"] taError["`TempMaster Error Value &lt;&lt;fdri:SystemProperty&gt;&gt;`"] err["`Error Value &lt;&lt;fdri:Variable&gt;&gt;`"] unitless["`Unitless &lt;&lt;fdri:Unit&gt;&gt`"] taSensor["`TempMaster &lt;&lt;fdri:EMSystemType&gt;&gt;`"] --hasSystemCapability--> taCap taCap["`Temp Master Error Capability &lt;&lt;fdri:SystemCapability&gt;&gt;`"] --forProperty--> ta taCap --hasSystemProperty--> taError taError --property--> err taError --value--> taErrorValue["-9999"] taError --unit--> unitless

Operating Range

An fdri:OperatingRange specifies the operational characteristics of a system. It can be used either to specify quality values for specific operational characteristics such as "maintenance schedule" or "operating voltage range", or it can be used without any such characteristics. If no operational characteristics are defined on an fdri:OperatingRange , then the resource is interepreted as specifying the conditions under which the system will operate normally. When conditions go beyond the specified ranges, a system is considered to be operating "out of range", which may affect the quality of its observations.

fdri:OperatingRange has the following properties: * sys:hasOperatingProperty optionally references the fdri:Variable which defines the operational characteristic that this operating range provides a value for. * sys:inCondition references the fdri:Condition resources that define the environmental conditions for this operating range. * schema:value , schema:minValue , schema:maxValue - a single value or, more typically, a value range for the characteristic (if one is provided). * fdri:unit - an fdri:Unit specifying the unit of measure of the value or value range (if one is provided).

classDiagram class OperatingRange["fdri:OperatingRange"] { schema:minValue: rdfs:Literal schema:maxValue: rdfs:Literal schema:value: rdfs:Literal } class Condition["fdri:Condition"] class Variable["fdri:Variable"] class Unit["fdri:Unit"] OperatingRange "0..*" --> "0..1" Variable: sys_hasOperatingProperty OperatingRange "0..*" --> "0..1" Unit: schema_unit OperatingRange "0..*" --> "1..*" Condition: sys_inCondition

The example below shows a statement that the fictional "TempMaster" sensor is expected to operate normally under a temperature range of -40°C to 80°C.

flowchart ta["`Air Temperature &lt;&lt;fdri:Variable&gt;&gt;`"] taCond["`Temperature -40 to +80 &lt;&lt;fdri:Condition&gt;&gt;`"] taOp["`TempMaster Operating Range &lt;&lt;fdri:OperatingRange&gt;&gt;`"] taSensor["`TempMaster &lt;&lt;fdri:EMSystemType&gt;&gt;`"] degc["`Degree Celsius &lt;&lt;fdri:Unit&gt;&gt;`"] taSensor --hasOperatingRange--> taOp taOp --inCondition--> taCond taCond --property--> ta taCond --minValue--> min["-40"] taCond --maxValue--> max["80"] taCond --unit--> degc

Survival Range

An fdri:SurvivalRange specifies operational lifetime characteristics of a system under certain environmental conditions. It can be used either to provide values of specific lifetime characteristics (e.g. battery lifetime), or it can be used without any characteristics. If used without any characteristics, the fdri:SurvivalRange specifies the environmental conditions under which a system remains undamaged. When those conditions are exceeded, the system is considered damaged in some way and in need of maintenance or replacement.

The structure of fdri:SurvivalRange is similar to that of fdri:OperatingRange : * sys:hasSurvivalProperty optionally references the fdri:Variable which defines the lifetime characteristic that this survival range provides a value for. * sys:inCondition references the fdri:Condition resources that define the environmental conditions for this survival range. * schema:value , schema:minValue , schema:maxValue - a single value or, more typically, a value range for the characteristic (if one is provided). * fdri:unit - an fdri:Unit specifying the unit of measure of the value or value range (if one is provided).

classDiagram class OperatingRange["fdri:SurvivalRange"] { schema:minValue: rdfs:Literal schema:maxValue: rdfs:Literal schema:value: rdfs:Literal } class Condition["fdri:Condition"] class Variable["fdri:Variable"] class Unit["fdri:Unit"] OperatingRange "0..*" --> "0..1" Variable: sys_hasSurvivalProperty OperatingRange "0..*" --> "0..1" Unit: schema_unit OperatingRange "0..*" --> "1..*" Condition: sys_inCondition

The following example shows a battery lifetime of 800 days for an imaginary "TempMaster" sensor under its normal operating conditions of -40°C to +80°C.

flowchart ta["`Air Temperature &lt;&lt;fdri:Variable&gt;&gt;`"] battLife["`Battery Lifetime &lt;&lt;fdri:Variable&gt;&gt;`"] taCond["`Temperature -40 to +80 &lt;&lt;fdri:Condition&gt;&gt;`"] taSurv["`TempMaster Battery Lifetime &lt;&lt;fdri:SurvivalRange&gt;&gt;`"] taSensor["`TempMaster &lt;&lt;fdri:EMSystemType&gt;&gt;`"] degc["`Degree Celsius &lt;&lt;fdri:Unit&gt;&gt;`"] days["`Days &lt;&lt;fdri:Unit&gt;&gt;`"] taSensor --hasSurvivalRange--> taSurv taSurv --hasSurvivalProperty--> battLife taSurv --inCondition--> taCond taSurv --value--> 800 taSurv --unit--> days taCond --property--> ta taCond --minValue--> min["-40"] taCond --maxValue--> max["80"] taCond --unit--> degc

Note on SOSA/SSN Systems Module Mapping

The modelling for fdri:Condition extends the SOSA/SSN sys:Condition . Under the SOSA/SSN model the class sys:Condition is declared as a subclass of ssn:Property . This is still true in the FDRI model, but rather than the condition property being inferred by the class of the condition, the property is explicitly stated using the fdri:property property. We believe this gives greater clarity and flexibility as it allows condition properties to be drawn from a controlled vocabulary of fdri:Variable instances rather than requiring new classes to be defined for each condition property.

The same approach has been taken for including sys:SystemProperty (extended as fdri:SystemProperty ).

The FDRI model also makes explicit the use of properties from the domain of schema:PropertyValue to capture values and ranges of values on the classes fdri:SurvivalRange (derived from sys:SurvivalRange ), fdri:OperatingRange (derived from sys:OperatingRange ), and fdri:Condition (from sys:Condition ).

Data Processing Configurations

To model data processing configurations, there are two broad options to consider depending on how such configuration information is mastered. If the configuration information is mastered and managed in the metadata store, then a structure is needed to represent individual configuration properties and their values. If the configuration is mastered and managed in an external system such as a source control repository, then it would be more sensible to only record a link to (a version of) that configuration rather than to try and reflect its content in the metadata store.

Data Processing Activities and Data Processing Configurations

classDiagram class Plan["prov:Plan"] class DPConfig["fdri:DataProcessingConfiguration"] class DPConfigType["fdri:DataProcessingConfigurationType"] class IntDPConfig["fdri:InternalDataProcessingConfiguration"] class ExtDPConfig["fdri:ExternalDataProcessingConfiguration"] class Concept["skos:Concept"] Activity <|-- DPActivity Plan <|-- DPConfig DPConfig --> DPConfigType: dct_type DPConfig <|-- IntDPConfig DPConfig <|-- ExtDPConfig DPConfigType --|> Concept

An fdri:DataProcessingConfiguration may be soft-typed with an fdri:DataProcessingConfigurationType which is a concept drawn from a data processing configuration type controlled vocabulary.

There are two subclasses defined for fdri:DataProcessingConfiguration . fdri:InternalDataProcessingConfiguration resources store configuration properties and their values in the metadata store. fdri:ExternalDataProcessingConfiguration resources refer to a configuration file stored in a source control repository.

Internal Data Processing Configuration

The fdri:InteralDataProcessingConfiguration class provides a structure for keeping a complete historic record of the data processing methods applied to a data set. The configuration is modelled as a collection of items, each item representing a data processing method that is applied along with the arguments passed into that method. Methods and their parameters are modelled as SKOS concepts with the method concept having an additional property to relate the method to the parameters that it accepts.

classDiagram class Plan["fdri:DataProcessingConfiguration"] class DPConfig["fdri:InternalDataProcessingConfiguration"] class COP["iop:Variable"] class EMFType["fdri:EnvironmentalMonitoringFacilityType"] class EMF["fdri:EnvironmentalMonitoringFacility"] class ConfigurationItem["fdri:ConfigurationItem"] class DataProcessingConfigurationType["fdri:DataProcessingConfigurationType"] class TimeSeriesDefinition["fdri:TimeSeriesDefinition"] Plan <|-- DPConfig DPConfig --> EMF: fdri_appliesToFacility DPConfig --> EMFType: fdri_appliesToSystem DPConfig --> COP: fdri_appliesToVariable DPConfig --> TimeSeriesDefinition: fdri_appliesToTimeSeries DPConfig --> ConfigurationItem: fdri_hadConfigurationItem DPConfig --> ConfigurationItem: fdri_hasCurrentConfigurationItem DPConfig --> DataProcessingConfigurationType: dct_type

An fdri:InternalDataProcessingConfiguration is used to capture a collection of configuration items that apply to part of the data processing pipeline.

The relation fdri:appliesToFacility relates a fdri:DataProcessingConfiguration to the fdri:EnvironmentalMonitoringFacility or fdri:EnvironmentalMonitoringFacilityType whose measurements are affected by the configuration. The relation fdri:appliesToTimeSeries relates an fdri:DataProcessingConfiguration to the time series affected by the configuration.

NOTE The use of fdri:appliesToVariable to relate an fdri:DataProcessingConfiguration to the variable affected by the configuration is deprecated in favour of using fdri:appliesToTimeSeries and may be removed from the model.

The relation fdri:hasCurrentConfigurationItem relates an fdri:DataProcessingConfiguration to one or more fdri:ConfigurationItem s, which provide the current set of configuration values for the processing. Each fdri:ConfigurationItem specifies a method (e.g. multiply, spike etc.); a property value (which may be a specific value or a min/max range); a fdri:phenomenonInterval which indicates the date range of the observations to be affected by the configuration item; and an fdri:interval which specifies the interval during which the configuration item applies. If fdri:phenomenonInterval is omitted, the configuration would be treated as applying to all observations processed during the fdri:interval

The relation fdri:hadConfigurationItem relates an fdri:DataProcessingConfiguration to the configuration items which were historically used by the configuration.

Configuration Item Strucutre

classDiagram class PropertyValue["schema:PropertyValue"] { schema:value: rdfs:Literal schema:minValue: rdfs:Literal schema:maxValue: rdfs:Literal schema:valueReference: rdfs:Resource fdri:valueType: rdf:Resource } class ConfigurationItem["fdri:ConfigurationItem"] class Param["fdri:ConfigurationParameter"] class Period["dcterms:PeriodOfTime"] class Method["fdri:DataProcessingMethod"] class Arg["fdri:ConfigurationArgument"] class Concept["skos:Concept"] ConfigurationItem --> Method: fdri_method ConfigurationItem --> Period: fdri_interval ConfigurationItem --> Period: fdri_observationInterval ConfigurationItem --> Arg: fdri_argument Method --> Param: fdri_parameter Arg --> Param: fdri_parameter Arg --> PropertyValue: fdri_hasValue ConfigurationItem --> ConfigurationItem: dct_replaces Method --|> Concept Param --|> Concept

An fdri:ConfigurationItem resource has: * a required fdri:method property which specifies the configuration method * a required fdri:interval property which specifies the processing data range during which the configuration item applies * an optional fdri:observationInterval property which specifies the date range of the observations to which the configuration item applies * zero or more fdri:argument properties that specify the arguments passed to the configuration method. * an optional dct:replaces property which relates the fdri:ConfigurationItem to the preceding fdri:ConfigurationItem which it replaces

An fdri:ConfigurationArgument resource has: * a required fdri:parameter property which specifies the configuration parameter that the argument provides a value for. * a required fdri:hasValue property which specifies the value of the argument.

An fdri:PropertyValue resource has: * schema:minValue and schema:maxValue to denote a value range. * schema:value to denote an single literal value. * schema:valueReference to provide a value that is another concept (e.g. a value from a taxonomy) * fdri:valueType to define the type of the value provided. If the value is a literal value or value range, then fdri:valueType should be the XML Schema Datatypes identifier for the datatype of the value(s). If the value is a reference to another concept then fdri:valueType should be the IRI of the RDF class of that concept.

Both fdri:DataProcessingMethod and fdri:ConfigurationParameter are subclasses of skos:Concept.

fdri:DataProcessingMethod also has: * an optional, repeatable property fdri:hasParameter which relates the method to the parameters that may be passed to the method.

QUESTION Is configuration history managed at the individual configuration property level or at the whole configuration level?

External Data Processing Configuration

classDiagram class Plan["fdri:DataProcessingConfiguration"] class DPConfig["fdri:ExternalDataProcessingConfiguration"] { fdri:repository: xsd:anyURI fdri:repositoryPath: xsd:string dct:version: xsd:string } Plan <|-- DPConfig

When configuration information is mastered externally, the model for the configuration captures only the URI of the external repository that contains the configuration, the path within that repository to the configuration, and a version identifier that identifies the specific version of the configuration resource (e.g. a git commit hash or a tag if tag-based deployment is used). The dct:type property can be used to provide a more specific configuration type drawn from a SKOS concept scheme may be useful when processes use multiple configuration files for different purposes.

Notes on Geo-spatial Resources

Several classes in the FDRI ontology represent geo-spatially located entities which are either persistent or temporary in nature. In particular fdri:EnvironmentalMonitoringFacility , fdri:GeospatialFeature and fdri:MobileDeployment . To facilitate a range of both machine and human access to geospatial data relating to these entities the model provides a number of distinct properties on these classes.

geos:hasGeometry MUST be provided and is intended to be used to provide the preferred geometry for the entity, whether this be a boundary, path or point. This property is intended to provide a consistently available property for machine processing of geospatial entities with some flexibility with regards to how the entity is described geospatially.

fdri:hasRepresentativePoint MUST be provided and MUST provide a POINT location for a representative point for the entity. This property is intended to provide a consistently available property for machine processing of geospatial entities as a set of point locations.

geo:lat and geo:long SHOULD be provided and SHOULD provide the WGS84 latitude and longitude of the same point as fdri:hasRepresentativePoint . These properties are intended to facilitate easy access to representative point information for API users.

spatialrelations:easting and spatialrelations:northing SHOULD be provided when the entity lies within the GB National Grid and SHOULD provide the easting and northing of the same point as fdri:hasRepresentativePoint . These properties are intended to facilitate easy access to representative point information for API users.

geos:hasCentroid MAY be used to provide the coordinates of a centroid point for the entity.

geos:hasBoundingBox MAY be used to provide the coordinates of a bounding box that contains the entity.

FDRI Fine-grained Metadata Store Ontology

Metadata

IRI
http://fdri.ceh.ac.uk/vocab/metadata
Title

FDRI Fine-grained Metadata Store Ontology

Version Info

0.4.1 DRAFT

Description

An ontology for the recording of dataset metadata, provenance information and related reference data for use in the fine-grained metadata store element of the FDRI project.

Classes

Activity Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ActivityType
Description

A Concept which defines a category of activity.

Sub Class Of Concept c
Restriction is in scheme op only Activity Type Scheme c

Activity Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ActivityTypeScheme
Description

A concept scheme that manages a controlled list of activity types.

Sub Class Of Concept Scheme c

Agent c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Agent
Description

An Agent is something that has responsibility for an activity that takes place, for the existence or modification of some resource, or for the activity of another Agent.

Sub Class Of
Super Class Of

Aggregation c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Aggregation
Description

Represents the aggregation of all values collected with a given frequency (fdri:resolution) over a given period of time (fdri:periodicity) using a given aggregation method (fdri:valueStatistic).

Sub Class Of Concept c
In Range Of aggregation op
Restriction

Annotation c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Annotation
Description

Annotations provide an extension point to the FDRI metadata model to allow a more diverse range of metadata to be captured than is explicitly allowed for in the model.

Each Annotation instance provides either a single value ( fdri:hasValue ) or a time-based series of values ( fdri:hasValueSeries ) for a single property ( fdri:property ).

In Range Of
Restriction

Array c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Array
Description

A multi-dimensional array contained in an fdri:GriddedDataset .

Sub Class Of Gridded Dataset Resource c
In Domain Of
Restriction references op min 0

Catchment Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/CatchmentScheme
Description

A concept scheme consisting of Catchment concepts.

Sub Class Of Concept Scheme c
In Range Of catchment scheme op

Condition c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Condition
Description

Used to specify ranges for qualities that act as conditions on a system/sensor's operation. For example, wind speed of 10-60m/s may be used as the condition on a SystemProperty, for example, to state that a sensor has a particular accuracy in that condition.

The fdri:property property references the fdri:Variable that defines the condition property. The properties schema:minValue and schema:maxValue may be used to express a value range for the condition, or the property schema:value used to express a single value. The property schema:unit MUST also be used to express the unit of measure for the condition.

Sub Class Of
Restriction

Data Processing Configuration Argument c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationArgument
Description

Represents a single argument passed to a configuration method as part of an fdri:ConfigurationItem .

In Range Of argument op
Restriction

Data Processing Configuration Item c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationItem
Description

Represents the configuration of a single data processing method to be applied to a subset of observations as part of a data processing pipeline run.

The property fdri:method references the concept that defines the data processing method applied. Each argument passed to the data processing method is provided through an fdri:argument property.

The property fdri:interval indicates the period of time during which this configuration item is/was used. The property fdri:observationInterval indicates the date range of the measurements that the configuration item applies to.

In Range Of
Restriction

Configuration Parameter c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationParameter
Description

Represents a single parameter that may be passed to an fdri:DataProcessingMethod as part of a data processing pipeline.

Sub Class Of Concept c
In Range Of parameter op
Restriction is in scheme op only Configuration Parameter Scheme c

Configuration Parameter Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationParameterScheme
Description

A concept scheme that manages a controlled list of configuration parameters.

Sub Class Of Concept Scheme c

Configuration Property c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationProperty
Description

A property of a system or process which may be altered in order to affect the way in which that system or process behaves.

Instances of this class are used to define the properties by which the behaviour of fdri:EnvironmentalMonitoringSystem s may be constrained or modified.

Sub Class Of Concept c
Restriction is in scheme op only Configuration Property Scheme c

Configuration Property Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationPropertyScheme
Description

A Concept Scheme that manages a collection of configuration property concepts.

Sub Class Of Concept Scheme c
In Range Of configiuration property scheme op

Configuration Value Series c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ConfigurationValueSeries
Description

A resources which provides the current and historically configured values for some configuration property.

Sub Class Of Property Value Series c
Restriction Type op only Configuration Property c

Data Processing Configuration c

IRI http://fdri.ceh.ac.uk/vocab/metadata/DataProcessingConfiguration
Description

The configuration information which is used by a data processing activity to control the way in which the processing activity behaves.

A Data Processing Configuration is defined as a sub-type of prov:Plan allowing it to be associated with an Actitvity via the prov:qualifiedAssociation property.

Sub Class Of
Restriction
Super Class Of

Data Processing Configuration Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/DataProcessingConfigurationType
Description

A Concept which defines a category of data processing configuration.

Sub Class Of Concept c
Restriction is in scheme op only Data Processing Configuration Type Scheme c

Data Processing Configuration Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/DataProcessingConfigurationTypeScheme
Description

A Concept Scheme which manages a controlled list of Data Processing Configuration Type concepts.

Sub Class Of Concept Scheme c

Data Processing Method c

IRI http://fdri.ceh.ac.uk/vocab/metadata/DataProcessingMethod
Description

A Concept which represents a data processing methodology/procedure and the parameters it can take.

Sub Class Of Concept c
Restriction parameter op min 0

Deployment c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Deployment
Description

Describes the deployment of one or more systems of sensors for some purpose.

A deployment may be associated with a platform on which the sensors or systems were deployed.

Sub Class Of
In Domain Of deployment note dp
Restriction
Super Class Of Static Deploment c

Dimension c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Dimension
Description

A single dimension of a multi-dimensional array contained in an fdri:GriddedDataset .

Sub Class Of Gridded Dataset Resource c

Environmental Domain c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalDomain
Description

A broad aspect of study of the natural environment.

Sub Class Of Concept c
In Range Of environmental domain op
Restriction is in scheme op only Environmental Domain Scheme c

Environmental Domain Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalDomainScheme
Description

A controlled vocabulary of Environmental Domain concepts.

Sub Class Of Concept Scheme c

Environmental Monitoring Activity c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringActivity
Description

An Activity which gives rise to a set of observations of some environmental feature of interest. Examples include sorties by UAV, a person counting plastic waste in a gridded area of a beach, or a team of people trapping and measuring the size and weight of fish.

An EnvironmentalMonitoringActivity may follow a documented Procedure, and may involve the completion of one or more sub-activities each with their own Procedures.

Sub Class Of
In Range Of
Restriction

Environmental Monitoring Facility Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringFacilityType
Description

A Concept that represents a class of Environmental Monitoring Facility as defined by the monitoring programme that uses it.

Sub Class Of Concept c
Restriction
Super Class Of Environmental Monitoring System Type c

Environmental Monitoring Facility Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringFacilityTypeScheme
Description

A controlled vocabulary of monitoring facility types.

Sub Class Of Concept Scheme c
In Range Of

Environmental Monitoring Network c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringNetwork
Description

A collection of infrastructure elements ( fdri:EnvironmentalMonitoringFacility ) which are used together for some environmental monitoring purpose.

Restriction contains op only Environmental Monitoring Facility c

Environmental Monitoring Platform c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringPlatform
Description

A piece of infrastructure at a site that is used in the monitoring of the environment at that site.

An Environmental Monitoring Platform may be a physical piece of infrastructure such as a post in the ground, a raised platform or a hole in the ground. It may also be used to represent a "slot" in the site infrastructure to which sensors may be serially deployed over time in order to monitor the same phenomenon.

An Environmental Monitoring Platform may host ( sosa:hosts ) any number of systems ( fdri:EnvironmentalMonitoringSystem ). It may also be the target of a Deployment ( fdri:deployedOnPlatform on fdri:Deployment ) of some fdri:EnvironmentalMonitoringSystem . This latter formulation is preferred when the system(s) deployed on the platform may change over time.

Sub Class Of

Environmental Monitoring Programme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringProgramme
Description

An activity which undertakes the monitoring of some aspect(s) of the natural environment.

An Environmental Monitoring Programme may make use of ( fdri:utilises ) any number of Environmental Monitoring Networks ( fdri:EnvironmentalMonitoringNetwork ) and/or Environmental Monitoring Facilities ( fdri:EnvironmentalMonitoringFacility ) in order to achieive its goals.

In Domain Of Relates an Environmental Monitoring Programme to the Environmental Monitoring Facility or Environmental Monitoring Network used by the programme in the delivery of its outputs. op
In Range Of
Restriction

Environmental Monitoring Sensor c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringSensor
Description

A device which responds to a stimulus such as a change in the environment and reports a resulting observation.

Sub Class Of
Restriction

Environmental Monitoring Site c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringSite
Description

A geo-spatial location which contains infrastructure elements to which environmental monitoring systms are deployed.

An Environmental Monitoring Site may host any number of systems ( fdri:EnvironmentalMonitoringSystem ) and it may be the target of any number of deployments ( fdri:deployedOnPlatform on fdri:Deployment ) of systems. This latter formulation should be used when the system(s) deployed to a site may change over time.

If information is available regarding the platforms ( fdri:EnvironmentalMonitoringPlatform ) at a site, then hosting and deployment relationships should target the platform(s) rather than the site where possible.

Sub Class Of
Restriction

Environmental Monitoring System c

IRI http://fdri.ceh.ac.uk/vocab/metadata/EnvironmentalMonitoringSystem
Description

An abstraction for a pieces of environmental monitoring infrastructure that may be deployed to provide observations of environmental features of interest.

Sub Class Of
Restriction
Super Class Of Environmental Monitoring Sensor c

External Data Processing Configuration c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ExternalDataProcessingConfiguration
Description

A Data Processing Configuration whose values are maintained in a system external to the FDRI metadata store.

The dct:version property of this class SHOULD be used to provide the commit hash, tag or other stable identifier of a specifiic version of the referenced configuration data in the source repository.

The dct:type property of this class SHOULD be used to reference the fdri:DataProcessingConfigurationType concept that defines the category of configuration data provided by the configuration.

Sub Class Of Data Processing Configuration c
Restriction

Environmental Monitoring Facility Group c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityGroup
Description

Represents a collection of related Environmental Monitoring Facilities.

Facility Groups may be geographic (e.g. region, catchment), administrative (e.g. local authority, commisioning group) or created for any other purpose.

Membership may be expressed directly using the fdri:hasMember property, or indirectly (with an optional temporal constraint) by creating fdri:FacilityGroupMembership instances.

Sub Class Of dcat:Resource
In Range Of group op
Restriction

Facility Group Membership c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityGroupMembership
Description

Represents an optionally time-bounded membership of an fdri:FacilityGroup by some fdri:EnvironmenalMonitoringFacility .

Restriction

Facility Group Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityGroupType
Description

A concept representing the nature of a facility group. e.g. catchment, region, project.

Sub Class Of Concept c
Restriction is in scheme op only Environmental Monitoring Facility Group Type Scheme c

Environmental Monitoring Facility Group Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityGroupTypeScheme
Description

A controlled vocabulary of monitoring facility group types.

Sub Class Of Concept Scheme c

Facility Usage Role c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityUsageRole
Description

A skos:Concept representing the role played by an fdri:EnvironmentalMonitoringFacility in an fdri:FacilityUsage relation. The role describes the way in which the facility is used by the fdri:EnvironmentalMonitoringActivity that encloses the fdri:FacilityUsage .

Sub Class Of Concept c
Restriction is in scheme op only Facility Usage Role Scheme c

Facility Usage Role Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/FacilityUsageRoleScheme
Description

A skos:ConceptScheme that manages a controlled list of fdri:FacilityUsageRole concepts.

Sub Class Of Concept Scheme c

Fault c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Fault
Description

A record of a fault that affects the capture of one or more variables ( fdri:affectedVariable ) by one or more monitoring facilities ( fdri:affectedFacility ) for a given period of time (`fdri:interval).

A fault may or may not require that data collected for the affected variables by the affected facilities be removed from the published datasets ( fdri:removeData ).

A persistent or unresolved fault may be represented by using an interval with no defined end time.

In Domain Of
Restriction

Geo-spatial Feature Of Interest c

IRI http://fdri.ceh.ac.uk/vocab/metadata/GeospatialFeatureOfInterest
Description

A Feature of Interest with a geospatial location.

Sub Class Of sosa:Sample
Restriction

Gridded Container c

IRI http://fdri.ceh.ac.uk/vocab/metadata/GriddedContainer
Description

A container for gridded data, typically used to organize and manage multiple gridded datasets as a single dataset. Referred to as groups in netCDF.

Sub Class Of Gridded Dataset Resource c
Restriction contains op only Gridded Dataset Resource c

Gridded Dataset c

IRI http://fdri.ceh.ac.uk/vocab/metadata/GriddedDataset
Description

A dataset in an array format such as ZARR or netCDF.

Sub Class Of Observation Dataset c
Restriction contains op only Gridded Dataset Resource c

Gridded Dataset Resource c

IRI http://fdri.ceh.ac.uk/vocab/metadata/GriddedDatasetResource
Description

Base type for resources which form the structure of a Gridded Dataset.

In Range Of references op
Restriction
Super Class Of

Internal Data Processing Configuration c

IRI http://fdri.ceh.ac.uk/vocab/metadata/InternalDataProcessingConfiguration
Description

A data processing configuration whose values are stored in the FDRI metadata service.

Configuration values are conveyed by a collection of Configiration Items ( fdri:ConfigurationItem ) referenced from this item using the properties fdri:hasCurrentConfiguration for items which represent currently active values, and fdri:hadConfiguration for items which represent historically active values.

A current configuration MAY consist of multiple fdri:ConfigurationItem instances providing configuration details for different data processing methods.

Sub Class Of Data Processing Configuration c
Restriction

Measure c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Measure
Description

Represents the measurement of a variable (fdri:variable) as recorded in a dataset using some consistent measurement unit (fdri:hasUnit) and an optional aggregation (fdri:aggregation).

Sub Class Of Concept c
In Domain Of has unit op
In Range Of
Restriction

Measure Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/MeasureScheme
Description

A controlled vocabulary of variable measures.

Sub Class Of Concept Scheme c

Observation Dataset c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ObservationDataset
Description

A dataset that provides values for Measures from some Environmental Monitoring Facility or Programme.

The property fdri:measure should be use to specify the Measures recorded by the dataset and sosa:observedProperty should be used to specify the Variables measured by those measures.

It is recommended that every dataset should specify the feature(s) of interest (sosa:hasFeatureOfInterest) observed by the measures in the dataset, and the originating programme (fdri:originatingProgramme) for the data. Datasets that provide observations from static sites should also reference these using the fdri:originatingSite property.

Sub Class Of dcat:Dataset
In Domain Of
Restriction
Super Class Of

Observation Dataset Series c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ObservationDatasetSeries
Description

A Dataset Series that groups a collection of related Observation Datasets together.

Sub Class Of

Operating Range c

IRI http://fdri.ceh.ac.uk/vocab/metadata/OperatingRange
Description

The FDRI ontology extends the SOSA/SSN class ssn-system:OperatingRange to restrict the range of ssn-system:hasOperatingProperty to fdri:Varaible as well as to make explicit the use of schema:minValue , schema:maxValue , schema:value and schema:unit to capture the survival property value and unit of measure.

Sub Class Of http://www.w3.org/ns/ssn/systems/OperatingRange
Restriction

Organization c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Organization
Description

A social or legal institution such as a company, society etc.

Sub Class Of

Person c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Person
Description

A natural person.

Sub Class Of

Procedure c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Procedure
Description

A process follwed by an Agent ( fdri:Agent ) during the execution of an Activity ( prov:Activity ).

The categorization of the procedure SHOULD be indicated using the dct:type property referencing an fdri:ProcedureType concept.

The periodicity ( fdri:procedurePeriodicity ) property SHOULD be used to capture the expected frequency of execution of the Procedure.

Sub Class Of
In Range Of has procedure op
Restriction
Super Class Of Time-series Plan c

Procedure Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ProcedureType
Description

A concept which defines a category or type of fdri:Procedure .

Sub Class Of Concept c
Restriction is in scheme op only Procedure Type Scheme c

Procedure Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ProcedureTypeScheme
Description

A controlled vocabulary of types or categories of procedure that might be undertaken by an Agent as (part of) an Activity.

Sub Class Of Concept Scheme c

Processing Level c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ProcessingLevel
Description

A concept which defines a level of data processing that has been applied to a dataset.

Sub Class Of Concept c
Restriction is in scheme op only Processing Level Scheme c

Processing Level Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ProcessingLevelScheme
Description

A controlled vocabulary of the levels of data processing which may be applied to a dataaset.

Sub Class Of Concept Scheme c

Programme Catalog c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ProgrammeCatalog
Sub Class Of dcat:Catalog
Restriction programme op exactly 1

Property Value c

IRI http://fdri.ceh.ac.uk/vocab/metadata/PropertyValue
Description

A structured representation of the value of a property, allowing for values that are simple values, value ranges, or classifications.

Sub Class Of schema:PropertyValue c
Restriction qualifier op min 0
Super Class Of

Property Value Series c

IRI http://fdri.ceh.ac.uk/vocab/metadata/PropertyValueSeries
Description

An record of values of a property. The currently active/valid value is given by fdri:hasCurrentValue and historic values are given by fdri:hadValue .

In Range Of has value series op
Restriction
Super Class Of Configuration Value Series c

Quality Observation c

IRI http://fdri.ceh.ac.uk/vocab/metadata/QualityObservation
Description

A type of sosa:Observation that provides quality metrics for some dcat:Dataset

Sub Class Of sosa:Observation
Restriction sosa:hasFeatureOfInterest only dcat:Dataset c

Region Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RegionScheme
Description

A controlled vocabulary of Regions.

Sub Class Of Concept Scheme c
In Range Of region scheme op

Related Party Association c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RelatedPartyAssociation
Description

An association between an Agent, the role that they play, and the procedure they followed, in relation to the referencing activity.

Sub Class Of Association c
Restriction

Related Party Attribution c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RelatedPartyAttribution
Description

An association between an Agent and the role that they play in relation to the referencing resource.

Sub Class Of Attribution c
Restriction

Related Party Role c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RelatedPartyRole
Description

A concept that defines the role an fdri:Agent may play in relation to some resource or activity.

Sub Class Of Concept c
Restriction is in scheme op only Related Party Role Scheme c

Related Party Role Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RelatedPartyRoleScheme
Description

A concept scheme that defines a controlled vocabulary for the roles that an Agent may play in relation to other resources.

Sub Class Of Concept Scheme c

Relative Location c

IRI http://fdri.ceh.ac.uk/vocab/metadata/RelativeLocation
Description

Specifies a geographic point as an offset from some contextually-defined reference point.

Restriction

Software Agent c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SoftwareAgent
Description

A software system

Sub Class Of Agent c
Restriction

Soil Type c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SoilType
Description

A concept that defines a soil type classification.

Sub Class Of Concept c
Restriction is in scheme op only Soil Type Scheme c

Soil Type Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SoilTypeScheme
Description

A concept scheme that defines a controlled vocabulary of soil type classifications.

Sub Class Of Concept Scheme c

Static Deploment c

IRI http://fdri.ceh.ac.uk/vocab/metadata/StaticDeployment
Description

A deployment of a sensor or system of sensors in a fixed relationship to some location.

Sub Class Of Deployment c
Restriction

Survival Range c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SurvivalRange
Description

The FDRI ontology extends the SOSA/SSN class ssn-system:SurvivalRange to restrict the range of ssn-system:hasSurvivalProperty to fdri:Varaible as well as to make explicit the use of schema:minValue , schema:maxValue , schema:value and schema:unit to capture the survival property value and unit of measure.en

Sub Class Of http://www.w3.org/ns/ssn/systems/SurvivalRange
Restriction

System Property c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SystemProperty
Description

The FDRI ontology definition of System Property extends the SOSA/SSN ssn-system:SystemProperty to use the property fdri:Property to reference the fdri:Variable that defines the system characteristic being measured.

In addition the use of schema:minValue , schema:maxValue , schema:value and schema:unit to capture the characteristic value is made explicity on this class.

Sub Class Of http://www.w3.org/ns/ssn/systems/SystemProperty
Restriction

System Status c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SystemStatus
Description

A concept that defines an operational status category for an Environmental Monitoring System.

Sub Class Of Concept c
Restriction is in scheme op only System Status Scheme c

System Status Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/SystemStatusScheme
Description

A controlled vocabulary of system status categories.

Sub Class Of Concept Scheme c

Time-bound Property Value c

IRI http://fdri.ceh.ac.uk/vocab/metadata/TimeBoundPropertyValue
Description

A value with an associated period of time during which the value is/was vaild.

Sub Class Of Property Value c
In Range Of
Restriction

Time-Series Dataset c

IRI http://fdri.ceh.ac.uk/vocab/metadata/TimeSeriesDataset
Description

A Observation Dataset consisting of a collection of values of one or more Measures of some Feature of Interest at regular intervals over a period of time.

This class extends fdri:ObservationDataset with metadata properties that assist in the processing of the data through the FDRI data pipeline. fdri:sourceBucket , fdri:sourceDataset and fdri:sourceColumnName are used to access the dataset values. The dct:type property references the fdri:TimeSeriesDefinition instance which provides processing configuration information for the dataset.

Sub Class Of Observation Dataset c
Restriction

Time-Series Definition c

IRI http://fdri.ceh.ac.uk/vocab/metadata/TimeSeriesDefinition
Description

A representation of a time series of some observed or derived measurement of a variable.

A Time-Series Definition captures the information that is common across multiple Time-Series Datasets that measure or derive values for the same Variable using the same procedure.

Sub Class Of Concept c
In Range Of uses op
Restriction

Time-series Plan c

IRI http://fdri.ceh.ac.uk/vocab/metadata/TimeSeriesPlan
Description

A procedure which results in the creation or update of instances of a Time-Series Definition ( fdri:TimeSeriesDefinition ) through the application of one or more data processing configurations ( fdri:DataProcessingConfiguration ) to it's input time series.

Sub Class Of Procedure c
Restriction

Unit of Measure c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Unit
Description

A Concept which represents a unit of measure of an observable property.

Sub Class Of Concept c
Restriction is in scheme op only Unit of Measure Scheme c

Unit of Measure Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/UnitScheme
Description

A concept scheme providing a controlled vocabulary of units of measure.

Sub Class Of Concept Scheme c

Value Statistic c

IRI http://fdri.ceh.ac.uk/vocab/metadata/ValueStatistic
Description

A concept that defines a statistical method for the derivation of a single aggregated value from a series of source values.

Sub Class Of Concept c
In Range Of value statistic op

Variable c

IRI http://fdri.ceh.ac.uk/vocab/metadata/Variable
Description

A variable whose definition also captures additional information about the context of each measurement of the property.

Sub Class Of
In Domain Of unit name dp
In Range Of
Restriction is in scheme op only Variable Scheme c

Variable Scheme c

IRI http://fdri.ceh.ac.uk/vocab/metadata/VariableScheme
Description

A concept scheme which manages a controlled set of Variable definitions.

Sub Class Of Concept Scheme c
In Range Of

Unit c

IRI http://qudt.org/schema/qudt/Unit
In Domain Of schema:unit op
In Range Of has unit op

Digital Document c

IRI http://schema.org/DigitalDocument
Description

An electronic file or document.

Sub Class Of dcat:Resource
In Range Of document op
Restriction schema:associatedMedia op min 0

Media Object c

IRI http://schema.org/MediaObject
In Range Of schema:associatedMedia op

Property Value c

IRI http://schema.org/PropertyValue
In Range Of has value op
Restriction
Super Class Of Property Value c

point c

IRI http://www.w3.org/2003/01/geo/wgs84_pos#Point
Description

  • Uniquely identified by lat/long/alt. i.e.

    spaciallyIntersects(P1, P2) :- lat(P1, LAT), long(P1, LONG), alt(P1, ALT), lat(P2, LAT), long(P2, LONG), alt(P2, ALT).

    sameThing(P1, P2) :- type(P1, Point), type(P2, Point), spaciallyIntersects(P1, P2).

  • A point, typically described using a coordinate system relative to Earth, such as WGS84.

Sub Class Of SpatialThing c

SpatialThing c

IRI http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing
Description

Anything with spatial extent, i.e. size, shape, or position. e.g. people, places, bowling balls, as well as abstract areas like cubes.

In Domain Of
In Range Of location op
Super Class Of point c

Entity c

IRI https://w3id.org/iadopt/ont/Entity
Sub Class Of Concept c

Property c

IRI https://w3id.org/iadopt/ont/Property
Description

A type of a characteristic of an iop:ObjectOfInterest .

Sub Class Of Concept c

Variable c

IRI https://w3id.org/iadopt/ont/Variable
Super Class Of Variable c

Object Properties

affected facility op

IRI http://fdri.ceh.ac.uk/vocab/metadata/affectedFacility
Description

Relates an fdri:Fault to the fdri:EnvironmentalMonitoringFacility whose operation is or may be affected by the Fault

Sub Property Of topObjectProperty op
Domain Fault c
Range Environmental Monitoring Facility c

affected variable op

IRI http://fdri.ceh.ac.uk/vocab/metadata/affectedVariable
Description

Relates an fdri:Fault to the fdri:Variable the observation of which is or may be affected by the fault.

Sub Property Of topObjectProperty op
Domain Fault c
Range Variable c

aggregation op

IRI http://fdri.ceh.ac.uk/vocab/metadata/aggregation
Description

Defines the statistical aggregation applied to observations to produce a measure.

Range Aggregation c

annotation property scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/annotationPropertyScheme
Description

References a controlled list of annotation properties used by this catalog.

Sub Property Of dcat:themeTaxonomy
Range Variable Scheme c

applies to facility op

IRI http://fdri.ceh.ac.uk/vocab/metadata/appliesToFacility
Description

Defines the Environmental Monitoring Facility that a data processing configuration applies to.

Sub Property Of topObjectProperty op
Range Environmental Monitoring Facility c

applies to time-series op

IRI http://fdri.ceh.ac.uk/vocab/metadata/appliesToTimeSeries
Description

Defines the Time-Series Dataset or Time-Series Definition that a Data Processing Configuration is used for.

Range Time-Series Definition c or Time-Series Dataset c

applies to variable op

IRI http://fdri.ceh.ac.uk/vocab/metadata/appliesToVariable
Description

Defines the Variable that a Data Processing Configuration is applied to.

Sub Property Of topObjectProperty op
Range Variable c

argument op

IRI http://fdri.ceh.ac.uk/vocab/metadata/argument
Description

An argument passed to the Data Processing Method of an Internal Data Processing Configuration.

Sub Property Of topObjectProperty op
Range Data Processing Configuration Argument c

catchment scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/catchmentScheme
Description

References a controlled list of Catchment areas referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Catchment Scheme c

certification op

IRI http://fdri.ceh.ac.uk/vocab/metadata/certification
Description

A reference to the document that certifies the system

Sub Property Of document op

configuration op

IRI http://fdri.ceh.ac.uk/vocab/metadata/configuration
Description

The current and historical configuration of one or more aspects of the parent resource.

Range Data Processing Configuration c or Configuration Value Series c

configiuration property scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/configurationPropertyScheme
Description

References a controlled list of configuration properties referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Configuration Property Scheme c

contains op

IRI http://fdri.ceh.ac.uk/vocab/metadata/contains

document op

IRI http://fdri.ceh.ac.uk/vocab/metadata/document
Description

A reference to a document that is related to the enclosing resource.

Super Property Of certification op
Range Digital Document c

environmental domain op

IRI http://fdri.ceh.ac.uk/vocab/metadata/environmentalDomain
Description

The domain(s) of environmental study that the observations of this facility relate to.

Range Environmental Domain c

facility usage op

IRI http://fdri.ceh.ac.uk/vocab/metadata/facilityUsage
Description

Relates the enclosing prov:Activity resource to an fdri:FacilityUsage qualified association resource that specifies the facility used and the role played by the facility in the activity.

Sub Property Of qualified usage op
Range Facility Usage c

group op

IRI http://fdri.ceh.ac.uk/vocab/metadata/group
Description

Defines the Environmental Monitoring Facility Group that participates in an Environmental Monitoring Facility Group Membership relation.

Range Environmental Monitoring Facility Group c

had configuration item op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hadConfigurationItem
Description

The configuration item that was part of the parent configuration at some past period in time.

Sub Property Of topObjectProperty op
Range Data Processing Configuration Item c

had value op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hadValue
Description

Defines a value which a property had at during some past period of time.

Range Time-bound Property Value c

has annotation op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasAnnotation
Description

Relates an item to the fdri:Annotation items that provide additional property values for that item.

Range Annotation c

has current configuration item op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasCurrentConfigurationItem
Description

The configuration item that is part of the parent configuration at the present time.

Sub Property Of topObjectProperty op
Range Data Processing Configuration Item c

has current value op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasCurrentValue
Description

The value that a property currently has.

Range Time-bound Property Value c

has member op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasMember
Description

Represents a simple group-membership relationship in which the subject of the statement is the group and the object of the statement the group member

has procedure op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasProcedure
Description

Relates a resource to a Procedure which may be applied to that resource.

Range Procedure c

has representative point op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasRepresentativePoint
Description

Provides a represenataive point location for an item which may have more complex spatial geometry assocaited with it.

Sub Property Of geos:hasGeometry

has unit op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasUnit
Description

Relates a Measure to the unit of measurement used by observations of the property.

Domain Measure c
Range http://qudt.org/schema/qudt/Unit c

has value op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasValue
Description

Provides the current value of the item (an fdri:Annotation or fdri:ConfigurationValue ).

This property should be used for annotations where it is not necessary to track an historical record of the annotation values over time, and should be used to provide the currently accepted value of the parent item.

When fdri:hasValueSeries is present on an item, this property SHOULD NOT be present on the same item.

Sub Property Of topObjectProperty op
Range schema:PropertyValue c

has value series op

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasValueSeries
Description

Provides a historical record of the values of the parent item (an fdri:Annotation) including the current annotation value.

When fdri:hasValue is present on an item, this property SHOULD NOT be present on the same item.

Sub Property Of topObjectProperty op
Range Property Value Series c

interval op

IRI http://fdri.ceh.ac.uk/vocab/metadata/interval
Description

Relates a time-bound property or relationship to the period of time during which that property or relationship was valid.

Range Period of Time

measure op

IRI http://fdri.ceh.ac.uk/vocab/metadata/measure
Description

Relates an ObservationDataset to a Measure that the dataset provides values for.

Domain Observation Dataset c
Range Measure c

measures op

IRI http://fdri.ceh.ac.uk/vocab/metadata/measures
Description

Relates a resource to the fdri:Measure that the resource has capacity to measure.

Range Measure c

member op

IRI http://fdri.ceh.ac.uk/vocab/metadata/member
Description

Defines the Environmental Monitoring Facility that is a member of some Environmental Monitoring Facility Group in a qualified Environmental Monitoring Facility Group Membership relationship.

Range Environmental Monitoring Facility c

method op

IRI http://fdri.ceh.ac.uk/vocab/metadata/method
Description

Relates a Data Processing Configuration Item to the data processing method that is configured.

Sub Property Of topObjectProperty op
Domain Concept c

methodology op

IRI http://fdri.ceh.ac.uk/vocab/metadata/methodology
Description

Relates a Time-Series Definition to the Plan that defines how instances of the Time-Series Definition are generated and/or updated.

Range Plan c

monitoring facility type scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/monitoringFacilityTypeScheme
Description

References a controlled list of monintoring facility types referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Environmental Monitoring Facility Type Scheme c

monitoring system type scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/monitoringSystemTypeScheme
Description

References a controlled list of monitoring system types referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Environmental Monitoring Facility Type Scheme c

observation interval op

IRI http://fdri.ceh.ac.uk/vocab/metadata/observationInterval
Description

Defines a time-slice of observations that a configuration item applies to. This is distinct from the interval which defines the period during which the configuration item is/was used in data processing.

Sub Property Of topObjectProperty op
Range Period of Time

observed property scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/observedPropertyScheme
Description

References a controlled vocabulary of Variables that is referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Variable Scheme c

operating period op

IRI http://fdri.ceh.ac.uk/vocab/metadata/operatingPeriod
Description

The period of time during which an Environmental Monitoring Facility is/was operational.

Range Period of Time

originating activity op

IRI http://fdri.ceh.ac.uk/vocab/metadata/originatingActivity
Description

The Environmental Monitoring Activities that give rise to the data contained in the enclosing dataset.

Range Environmental Monitoring Activity c

originating facility op

IRI http://fdri.ceh.ac.uk/vocab/metadata/originatingFacility
Description

Relates a dataset of observations to the Environmental Monitoring Facility from which the observations originated. The choice of facilit(ies) to use as the value of this property should be restricted to those which apply to all observations in the temporal range of the dataset (such as a site or a platform), and not to facilities which might be replaced over the time span of the dataset (such as a replacable sensor or sensor package).

Sub Property Of topObjectProperty op
Super Property Of originating site op
Domain Observation Dataset c
Range Environmental Monitoring Facility c

originating programme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/originatingProgramme
Description

The environmental monitoring programme that intiated the activities that resulted in the production of this dataset.

Domain Observation Dataset c
Range Environmental Monitoring Programme c

originating site op

IRI http://fdri.ceh.ac.uk/vocab/metadata/originatingSite
Description

Relates a dataset of observations to the Environmental Monitoring Site from which the observations originated.

Sub Property Of originating facility op

parameter op

IRI http://fdri.ceh.ac.uk/vocab/metadata/parameter
Description

Relates a Data Processing Method to one of the paramters that the method takes, or a Data Processing Configuration Argument to the parameter that it provides a value for.

Sub Property Of topObjectProperty op
Range Configuration Parameter c

programme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/programme
Description

Relates a Programme Catalog to the Environmental Monitoring Programme that the catalog covers.

Range Environmental Monitoring Programme c

property op

IRI http://fdri.ceh.ac.uk/vocab/metadata/property
Description

References the fdri:Variable which describes the property for which an fdri:Annotation provides a value or value series.

Range Variable c

qualifier op

IRI http://fdri.ceh.ac.uk/vocab/metadata/qualifier
Description

Provides an additional qualifier value for an annotation value.

Range Annotation c

references op

IRI http://fdri.ceh.ac.uk/vocab/metadata/references
Description

An Array may reference one or more other gridded dataset resources (other arrays or dimensions).

Domain Array c
Range Gridded Dataset Resource c

region scheme op

IRI http://fdri.ceh.ac.uk/vocab/metadata/regionScheme
Description

References a controlled list of geographical regions that are referenced by the catalog.

Sub Property Of dcat:themeTaxonomy
Range Region Scheme c

status op

IRI http://fdri.ceh.ac.uk/vocab/metadata/status
Description

The operational status of an Environmental Monitoring System.

uses op

IRI http://fdri.ceh.ac.uk/vocab/metadata/uses
Description

Relates a Time Series Plan for the production of some Time Series to the Time Series Definitions that define the input Time Series used by the plan.

Range Time-Series Definition c

Relates an Environmental Monitoring Programme to the Environmental Monitoring Facility or Environmental Monitoring Network used by the programme in the delivery of its outputs.utilises op

IRI http://fdri.ceh.ac.uk/vocab/metadata/utilises
Domain Environmental Monitoring Programme c
Range Environmental Monitoring Network c or Environmental Monitoring Facility c

value statistic op

IRI http://fdri.ceh.ac.uk/vocab/metadata/valueStatistic
Description

Relates an aggregated data resource to the type of aggregation applied.

Range Value Statistic c

value type op

IRI http://fdri.ceh.ac.uk/vocab/metadata/valueType
Description

The type of the value of the enclosing resource.

On a schema:PropertyValue resource, the value of this property should be the IRI of the datatype of minValue , maxValue and/or value or the IRI of the class of the resource referenced by valueReference .

On an fdri:Measure resource, this property specifies the expected datatype for observed values of the fdri:Measure .

When this property is used to convey a datatype for minValue , maxValue and/or value , the datatypes defined by XML Schema 1.1 SHOULD be used.

variable op

IRI http://fdri.ceh.ac.uk/vocab/metadata/variable
Description

Relates a Measure to the Variable that is measured.

Range Variable c

was modified by op

IRI http://fdri.ceh.ac.uk/vocab/metadata/wasModifiedBy
Description

Relates a resource to the activity that modified the resource in some way.

Sub Property Of was influenced by op
Domain Observation Dataset c

replaces op

IRI http://purl.org/dc/terms/replaces

type op

IRI http://purl.org/dc/terms/type

associated media op

IRI http://schema.org/associatedMedia
Range schema:MediaObject c

unit op

IRI http://schema.org/unit
Domain http://qudt.org/schema/qudt/Unit c

value reference op

IRI http://schema.org/valueReference

location op

IRI http://www.w3.org/2003/01/geo/wgs84_pos#location
Description

The relation between something and the point, or other geometrical thing in space, where it is. For example, the realtionship between a radio tower and a Point with a given lat and long. Or a relationship between a park and its outline as a closed arc of points, or a road and its location as a arc (a sequence of points). Clearly in practice there will be limit to the accuracy of any such statement, but one would expect an accuracy appropriate for the size of the object and uses such as mapping .

Sub Property Of http://xmlns.com/foaf/0.1/based_near ap
Range SpatialThing c

Datatype Properties

aggregation period dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/aggregationPeriod
Description

The duration of time over which an time-series aggregation applies.

Range xsd:duration

altitude dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/altitude
Description

Height above sea-level measured in metres.

Range xsd:decimal

asset number dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/assetNumber
Description

An identifier assigned to a piece of infrastructure or equipment by the entity that is responsible for the management of that item.

Range xsd:string

calibration due dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/calibrationDue
Description

The date or date/time by which an instrument is due to be (re)calibrated.

Range xsd:dateTime c or xsd:date c

canopy height dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/canopyHeight
Description

The observed height of the tree canopy (in metres above ground level) at the time of the deployment.

Range xsd:decimal

date of disposal dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/dateOfDisposal
Description

The date on which an item was disposed of by the entity that manged it up to that date.

Sub Property Of Date p
Range xsd:date

date of purchase dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/dateOfPurchase
Description

The date on which an item was purchased by the entity that manages it.

Sub Property Of Date p
Range xsd:date

dependency note dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/dependencyNote
Description

A note regarding dependency of the enclosing Deployment.

Sub Property Of deployment note dp

deployed depth dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/deployedDepth
Description

The depth (in metres) below ground level at which an environmental monitoring system is deployed.

Range xsd:decimal

deployed height dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/deployedHeight
Description

The height (in metres) above ground level at which an environmental monitoring system is deployed.

Range xsd:decimal

deployment note dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/deploymentNote
Description

A note provinding some additional contextual information about the deployment of a system.

More specific sub-properties fdri:dependencyNote and fdri:deploymentVariance are provided to capture specific types of note and should be used where appropriate in preference to this property.

Sub Property Of topDataProperty dp
Super Property Of
Domain Deployment c

deployment position dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/deploymentPosition
Description

Descriptive information about the positioning of an Environmental Monitoring System as the result of the containing StaticDeployment activity

Range langString

deployment variance dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/deploymentVariance
Description

Descriptive information about the way in which the deployment of an Environmental Monitoring System differs from the standard deployment of a system of its type.

Sub Property Of deployment note dp
Range langString

elevation dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/elevation
Description

The height offset of a relative location from its origin, measured in metres.

Sub Property Of topDataProperty dp
Range xsd:decimal

has shape dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/hasShape
Description

A property specifying the shape of a multidimensional array as a list of the integer size of each dimension of the array.

is coordinate dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/isCoordinate
Description

Indicates if the containing fdri:Array is a co-ordinate variable, having a single dimension of the same name in the containing netCDF file.

Domain Array c
Range xsd:boolean

is mobile dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/isMobile
Description

True if this Environmental Monitoring Facility is not static when reporting measurements. e.g. a UAV, ship

Range xsd:boolean

offset east dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/offsetEast
Description

The easterly offset of a relative location from its origin, measured in metres.

Sub Property Of topDataProperty dp
Range xsd:decimal

offset north dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/offsetNorth
Description

The northerly offset of a relative location from its origin measured in metres.

Sub Property Of topDataProperty dp
Range xsd:decimal

periodicity dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/periodicity
Description

The duration over which an time-based aggregation applies.

Sub Property Of topDataProperty dp
Range xsd:duration

procedure periodicity dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/procedurePeriodicity
Description

How frequently a process or procedure should be carried out.

Range xsd:duration

remove data dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/removeData
Description

True if data that was measured during the existence of a Fault should be removed from the observation dataset.

Range xsd:boolean

source control repository dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/repository
Description

The IRI of the source control repository which holds the source code for a prov:SoftwareAgent.

Range xsd:anyURI

source control repository path dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/repositoryPath
Description

A repository-relative path to the files or directories that contain the data processing configuration values.

resolution dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/resolution
Description

The duration between the individual measurements that are aggregated to produce an aggregate value.

Sub Property Of topDataProperty dp
Range xsd:duration

serial number dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/serialNumber
Description

The unique identifier assigned to a piece of equipment by its manufacturer.

Range xsd:string

settle-in period dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/settleInPeriod
Description

The period of time required from the deployment of a sensor to its measurements being reliable due to the settling of the surrounding environment following the deployment.

Sub Property Of topDataProperty dp
Range xsd:duration

shape dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/shape
Description

The shape of the enclosing fdri:Array

Domain Array c

site variance dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/siteVariance
Description

Descriptive information about the way in which the layout of an Environmental Monitoring Facility differs from the standard layout for a facility of its type.

Range langString

size dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/size
Description

The size of the enclosing fdri:Dimension

source bucket dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/sourceBucket
Description

A reference to the AWS S3 bucket that contains the data for an FDRI dataset.

Range xsd:string

source column name dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/sourceColumnName
Description

The name of the column within a source dataset that contain values for an FDRI dataset.

Range xsd:string

source dataset dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/sourceDataset
Description

The name of the dataset in an AWS S3 bucket which contains the values for an FDRI dataset.

Range xsd:string

storage location dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/storageLocation
Description

The place in which a piece of infrastructure is currently stored.

Range xsd:string

unit name dp

IRI http://fdri.ceh.ac.uk/vocab/metadata/unitName
Description

Provides the display label to use for the unit of measurement of a Complex Observable Property.

Domain Variable c
Range langString

max value dp

IRI http://schema.org/maxValue
Range Literal

min value dp

IRI http://schema.org/minValue
Range Literal

value dp

IRI http://schema.org/value
Range Literal

latitude dp

IRI http://www.w3.org/2003/01/geo/wgs84_pos#lat
Description

The WGS84 latitude of a SpatialThing (decimal degrees).

Domain SpatialThing c

longitude dp

IRI http://www.w3.org/2003/01/geo/wgs84_pos#long
Description

The WGS84 longitude of a SpatialThing (decimal degrees).

Domain SpatialThing c

Annotation Properties

altitude ap

IRI http://www.w3.org/2003/01/geo/wgs84_pos#alt
Description

The WGS84 altitude of a SpatialThing (decimal meters above the local reference ellipsoid).

Domain SpatialThing c

location ap

IRI http://www.w3.org/2003/01/geo/wgs84_pos#location
Description

The relation between something and the point, or other geometrical thing in space, where it is. For example, the realtionship between a radio tower and a Point with a given lat and long. Or a relationship between a park and its outline as a closed arc of points, or a road and its location as a arc (a sequence of points). Clearly in practice there will be limit to the accuracy of any such statement, but one would expect an accuracy appropriate for the size of the object and uses such as mapping .

Sub Property Of http://xmlns.com/foaf/0.1/based_near ap
Range SpatialThing c

based_near ap

IRI http://xmlns.com/foaf/0.1/based_near
Super Property Of location op

Namespaces

:
http://fdri.ceh.ac.uk/vocab/metadata/
dcat
http://www.w3.org/ns/dcat#
dct
http://purl.org/dc/terms/
geo
http://www.w3.org/2003/01/geo/wgs84_pos#
geos
http://www.opengis.net/ont/geosparql#
iop
https://w3id.org/iadopt/ont/
ns1
http://fdri.ceh.ac.uk/vocab/
owl
http://www.w3.org/2002/07/owl#
prov
http://www.w3.org/ns/prov#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
schema
http://schema.org/
skos
http://www.w3.org/2004/02/skos/core#
sosa
http://www.w3.org/ns/sosa/
spatialrelations
http://data.ordnancesurvey.co.uk/ontology/spatialrelations/
ssn
http://www.w3.org/ns/ssn/
xsd
http://www.w3.org/2001/XMLSchema#

Legend

c Classes
op Object Properties
dp Datatype Properties
ap Annotation Properties