ABIS Parts
Figure 1. An overview of the major model parts of ABIS. The models shown here are detailed in the Multiple Models section. Overlaps indicated shared model elements.

1. Metadata

IRI

https://linked.data.gov.au/def/abis

Name

Australian Biodiversity Information Standard

Definition

This document is the normative specification of the Australian Biodiversity Information Standard (ABIS) and includes its authoritative statements on parts, requirements and patterns.

Created Date

2021-10-24

Modified Date

2024-01-03

Issued Date

2023-12-04

Version

2.1

Version IRI

abis:2.1

History Note

2.1 - 2024 Jan - Implementation of ABIS Projects Model and ABIS Data Release Model within ABIS
2.0 - 2023 Nov - Produced by DCCEEW for initial BDR operations. Includes handling of systematic surveys and project information.
1.0 - 2022 Jun - Initial version of ABIS. Tested with SURROUND Australia Pty Ltd and used for an initial national data acquisition survey for the BDR

Creator

Originally Department of Agriculture, Water and the Environment (DAWE),
now the Department of Climate Change, Energy and the Environment (DCCEEW)

Owner

Australian Biodiversity Information Governance Group (AUSBIGG)

Publisher

Department of Climate Change, Energy and the Environment (DCCEEW)

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Contacts

AusBIGG is supported by DCCEEW’s' Biodiversity Data Repository (BDR) Team. Contact the BDR Team on bdr@dcceew.gov.au

Issue tracking of the ABIS standard is managed online at https://github.com/AusBIGG/abis/issues

Code Repository

https://github.com/AusBIGG/abis

2. Abstract

This document is the normative specification of the Australian Biodiversity Information Standard (ABIS) and includes its authoritative statements on parts, requirements and patterns.

Note

The one-stop-shop for ABIS is the ABIS Portal. It contains example data, vocabularies and validators that you can play with online, without needing to install anything. Go there if you are new to ABIS.

3. Preamble

3.1. Parts of ABIS

The Australian Biodiversity Information Standard (ABIS) is a multi-part standard and this document is its normative specification.

The other parts of ABIS are:

  • Overview Document

  • Profile Definition

    • The technical expression of ABIS as a standard that inherits from other standards

    • This is available in human- and machine-readable forms

  • Models

    • ABIS is made of multiple models which are listed in the Models Section but are published and maintained elsewhere

    • Both human- and machine-readable forms of all ABIS models are available

  • Vocabularies

    • ABIS, and the modes it depends on, rely on many vocabularies

    • These are listed in the Vocabularies Section but are published and maintained elsewhere

  • Validators

    • Data 'shape' files that can be used with validation tooling to check conformance of data to ABIS

    • These are listed in the Validation Section but are published and maintained elsewhere

  • Mappings

    • Mappings of ABIS to/from other well-known standards or models in the same domain are given in the Mappings Section

  • Data Objects

    • RDF expressions of this Standard, JSON-LD context files and RDF forms of the mappings are given in the sections that describe the human-readable forms of those objects

3.2. Namespaces

Namespaces are used within the identifiers for model elements to ensure that they are globally unique. For example, the TERN Ontology's Sample class is identified by the IRI https://w3id.org/tern/ontologies/tern/Sample which distinguishes it from the SOSA Sample class, identified with http://www.w3.org/ns/sosa/Sample that it is based on but extends.

Namespaces are used in shortened form in documents and data by assigning them a prefix and the prefixes used in this document are given in the table below.

Prefix

Namespace

Description

abis:

https://linked.data.gov.au/def/abis/

ABIS namespace - for this Standard

abisp:

https://linked.data.gov.au/def/abis/projects/

ABIS Projects Model namespace

bdr:

https://linked.data.gov.au/dataset/bdr/

BDR Dataset Namespace

dr:

https://linked.data.gov.au/def/abis/data-release/

ABIS Data Release Model namespace

dt:

https://linked.data.gov.au/def/abis/datatypes/

ABIS Datatype Register namespace

ego:

https://w3id.org/idn/def/ego/

Extended Geometries Ontology

ex:

http://example.com/

Generic examples namespace - does not resolve

geo:

http://www.opengis.net/ont/geosparql#

GeoSPARQL Ontology namespace

owl:

http://www.w3.org/2002/07/owl#

Web Ontology Language ontology namespace

rdfs:

http://www.w3.org/2000/01/rdf-schema#

RDF Schema ontology namespace

sosa:

http://www.w3.org/ns/sosa/

Sensor, Observation, Sample, and Actuator (SOSA) ontology namespace

sdo:

https://schema.org/

schema.org namespace

skos:

http://www.w3.org/2004/02/skos/core#

Simple Knowledge Organization System (SKOS) ontology namespace

tern:

https://w3id.org/tern/ontologies/tern/

TERN Ontology namespace

time:

http://www.w3.org/2006/time#

Time Ontology in OWL namespace

void:

http://rdfs.org/ns/void#

Vocabulary of Interlinked Data (VoID) ontology namespace

xsd:

http://www.w3.org/2001/XMLSchema#

XML Schema Definitions ontology namespace

Using the table above, the TERN Ontology's Sample class would be identified as tern:Sample and the SOSA Sample class as sosa:Sample.

Note

A JSON-LD context built from this namespaces table is available as another resource within the ABIS specification and is online at:

3.3. Terms & Definitions

The following terms & definitions are used throughout this document.

ABIS

The Australian Biodiversity Standard - the data standard this document is about

BDR

Biodiversity Data Repository - a data collection managed by the Department of Climate Change, Energy and the Environment that incorporates biodiversity observations from State & Territory jurisdictions and aims to incorporate non-government data too

Blank Node

A Blank Node is a node within RDF data that does not have a globally unique or even persistent identifier, instead it is a node that is identifiable only in relation to the other nodes in the RDF data in which it is recorded. Blank Nodes are used to convey things that are entirely dependent on, and meaningless without, other things, for example values for Result classes.

IRI

An Internationalized Resource Identifier is a web address-style URL that is used as an identifier for something. It may be for a real-world object, e.g. https://linked.data.gov.au/dataset/qldgeofeatures/AnakieProvince identifies the Queensland Geological Feature Anakie Province or for data only, e.g. https://w3id.org/tern/ontologies/tern/Text which identifies the class of 'Text' - textual results - within the TERN Ontology.

IRIs do not have to resolve - go somewhere online when clicked - but they do have to follow all the rules for URLs, such as no spaces.

Class

Based on the mathematical notion of a set, within formal OWL modelling, a class is a set of objects exhibiting common properties. For example, the set of all people who are studying could be defined as being within a Student class.

Knowledge Graph

A data holding that implements node-edge-node (graph) data structures. The 'knowledge' part is often taken to indicate that the graph contains refined information, not just pure, raw, data.

Linked Data

A series of technologies and methodologies for the publication of data on the Internet. Uses RDF as its underlying data structure, OWL as its data model and the common mechanics of the Domain Name System (DNS) and the Hypertext Transfer Protocol (HTTP) to identify and share its data.

OWL

The OWL 2 Web Ontology Language, informally OWL 2, is an ontology language for the Semantic Web with formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents. Reference: OWL2

Predicate

Predicates, within formal OWL modelling, are the defined relations between objects of different classes (see Class) and also between objects and simple data values such as numbers and dates. For example, if Person X "knows" Person Y, then we can use a predicate of knows to relate them.

Frequently we use predicates already defined in existing ontologies. "knows", for example, is defined in the schema.org ontology SDO to be "The most generic bi-directional social/work relation".

RDF

The Resource Description Framework (RDF) is a data structure for representing information on the Web. RDF is made of identified nodes linked by typed edges that form graphs. Node/edge/node associations are often called 'triples'. Reference: RDF

Semantic Web

A vision of a machine-understandable Internet, created in the year 2000, and thought to be attainable through the use of Linked Data.

SPARQL

SPARQL is a query language for RDF. SPARQL matches patterns within RDF data to extract subsets of a graph. The results of SPARQL queries can be subset graphs or data in tabular form.

3.4. Conventions

Figures

In this document, figures showing model elements use the following key:

ABIS Parts
Figure 2. Key of model figure elements. Activity, Entity and Agent are classes from The Provenance Ontology and indicate temporal events, all manner of things and people and organisations with agency, respectively. Where prefix:ElementID is used, the prefix refers to entries in the Namespaces table.

Code

Where examples of ABIS data are given in this document, RDF data serialised in the Turtle format is used. For example:

PREFIX : <https://example.om/dataset/>
PREFIX sdo: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

:x
    a tern:RDFDataset ;
    sdo:name "Dataset X" ;
    sdo:hasPart <https://example.om/dataset/sample/y> ;
.

<https://example.om/dataset/sample/y>
    a tern:Sample ;
    sdo:name "Sample Y" ;
.

The above example data, while invalid according to the ABIS Validator, provides a simple example of a dataset and a sample and a relationship between them, encoded in Turtle.

4. Introduction

This document is the specification of the parts, requirements and patterns of the Australian Biodiversity Information Standard (ABIS).

The goal of ABIS is to simplify the exchange of standardised biodiversity data in Australia between data holders - States & Territories, the Commonwealth, educational and research organisations, private companies and the public - by providing a scientific observations data model and a series of additions to it that cater for institution details, data management and mappings to other information models.

ABIS uses rigorous and formal data models which means that data wanting to be compliant with it can be automatically validated using machine-readable forms of the models and validation tools. This specification indicates where the validators are and how to use them in the Validation Section.

4.1. Multiple Models

ABIS is centred on the TERN Ontology - see Figure 1 - which is a data model that represents ecological survey information. The TERN Ontology is designed in accordance with the principles of the Observations & Measurement standard ISO19156 that separates acts of observation from the results of those observations and ever-present details of the things observed.

The TERN Ontology itself inherits most of its modelling from several general-purpose and well-known Semantic Web models (ontologies), in particular:

Each of these "background models" are shown in Figure 1.

In addition to the TERN Ontology and the background models it uses, ABIS also use other "background models":

ABIS also includes additional "component models" that extend the range of things ABIS can cover:

Details of all these models are given in the Models section.

4.2. Background

Aim

ABIS was established to enable a national Biodiversity Data Repository BDR in Australia that absorbs data from a range of sources.

These data supplier sources - Australian State & Territories and other organisations such as museums, herbaria, research organisations and companies - have been collecting biodiversity data for over a century in Australia and have been doing so independently, so there is a wide range of information collected relating to where, when and how species are observed.

Since the BDR aims for a comprehensive and up-to-date data holding, it needs to be able to absorb large volumes of biodiversity data and process them quickly. Given that existing source data collections contain millions of observations, this is only achievable through automatic data processing.

To enable effective automatic processing of data - both in terms of effort and quality - common models and formats must be implemented by data suppliers who map their data holdings to a form that can be automatically assessed (validated) and processed. ABIS is that form.

History

The TERN Ontology was created in 2020 for TERN to use for their own observations Knowledge Graph.

In 2021, the BDR adopted the TERN Ontology as its base.

In 2022, the first version of ABIS was created, building on top of the TERN Ontology to cater for messaging methods and some aspects of data management, such as the withholding of data publication due to data embargoes. This version of ABIS was used to for the data acquired in November 2022 through the scan of State & Territory biodiversity observation data holdings.

At the end of 2023, version 2.0 of ABIS was created which removed all representation of messaging protocols, requirements and rules. Version 2.0 focuses on building on top of the TERN Ontology data elements used to manage and provide access to expected BDR data holdings.

4.3. Governance

ABIS is managed day-to-day by the Department of Climate Change, Energy, the Environment and Water (DCCEEW) however many parts of ABIS are maintained externally, such as the TERN Ontology which is maintained by TERN.

To contact the ABIS managers, please see use the following details:

BDR Team
Biodiversity Information Section
Department of Climate Change, Energy, the Environment and Water
https://www.dcceew.gov.au
bdr@dcceew.gov.au

Governance of ABIS is undertaken by AusBIGG, the Australian Biodiversity Information Governance Group, which comprises DCCEEW, State & Territory biodiversity data holders and other organisations in the sector, such as TERN.

As of 2023, the processes for maintaining and extending ABIS are not fully established with AusBIGG still coming to understand ABIS' uses and its place in the landscape of international biodiversity observation data models, such as GBIF’s New Data Model.

An Issue Tracker for this document and for any other aspects of ABIS is public and online at: https://github.com/AusBIGG/abis/issues. Anyone with an interest in ABIS is invited to submit Issues there to be considered by ABIS management & governance parties.

ABIS comprises multiple models and some of them inherit from other models and standards. See the Models section for details.

Additionally, ABIS exists within a domain that already contains many international and national standards and well-known models. The Mappings section described how ABIS relates to many of them.

4.5. Structure

This specification aims to cover all the information needed to understand ABIS and use it. The following is a list of the major sections in this document and their purposes.

  1. Introduction

    • This section. An informal overview of ABIS

  2. Patterns

    • Descriptions of important modelling choices made in ABIS and the models it inherits from

  3. Models

    • The normative description of the data models used within ABIS

  4. Vocabularies

    • Description of, and links to, the vocabularies needed for use with ABIS

  5. Profiles

    • A listing of known profiles of ABIS

  6. Validation

    • How to validate data according to ABIS and links to the various validators

  7. Mappings

    • Human- and machine-readable mappings between ABIS and other standards within ABIS' domain

Two additional models - extensions to ABIS - are defined in this document:

Extended examples TERN Ontology data, in use within ABIS, are given in Annex C.

5. Patterns

This section describes some modelling patterns implemented in ABIS. Most of these patterns are inherited from the models that ABIS profiles.

5.1. Set Modelling

The most basic pattern used by this model and all the OWL-based models it profiles is that of Set Theory modelling, that is, modelling according to the mathematical notion of sets.

The basic principles are that things - all things - can be modelled as atomic objects and groups of objects known as sets. The basic object/set relations (membership of an object within a set) and set/set relations (union, intersection, disjoint etc.) are likely familiar to all Australian high school graduates.

In OWL modelling, objects are usually called Named Individuals or Instances and sets are called Classes.

The set of all people, the class Person is defined like this:

ex:Person
    a owl:Class ;
    sdo:name "Person" ;
    sdo:description "Persons are individuals of the species Homo sapiens" ;
.

Nicholas Car is an object in the set of Person so, in OWL modelling, Nicholas Car is a Named Individual of type Person:

ex:nicholasCar
    a ex:Person ;
    sdo:name "Nicholas Car" ;
    sdo:description "Nicholas is a Person, born in South Africa, now living in Brisbane" ;
.

Subsetting is very important in OWL: Nicholas Car might also be an Engineer where Engineer is defined as a subset of Person. This means every Engineer is also a Person but not all Person objects are Engineers:

ex:nicholasCar
    a ex:Engineer ;
    sdo:name "Nicholas Car" ;
    sdo:description "Nicholas is an Engineer, born in South Africa, now living in Brisbane" ;
.

ex:Engineer rdfs:subClassOf ex:Person .

In OWL modelling, classes may be seen by grouping instances with similar properties. Nicholas Car might be understood to be an Australian by virtue of the predicate citizenship being given for him indicating Australian:

ex:nicholasCar
    a ex:Person ;
    sdo:name "Nicholas Car" ;
    ex:citizenship ex:Australian ;
.

The figure below shows Nicholas Car, the individual, declared as a Person, and Engineer and understood to be an Australian.

Set Modelling
Figure 3. Set Modelling using OWL: The Named Individual Nicholas Car and three Classes he is a member of and which are subclasses of others.

In the domain of ABIS, all animals living in the sea constitute the class marine animals and there are intersecting classes of terrestrial animals for things like crabs and penguins that live both in the sea and on land.

5.2. Identifiers

All objects in OWL modelling - classes, predicates and instances of classes - are identified either with an IRI or a Blank Node. Classes and predicates defined in ABIS or inherited from models it profiles use the identifiers for them given in this document. Instances of classes, for example a particular sample, Sample Y of the class Sample, are identified by IRIs assigned to them often deriving from the IRI of an identified dataset in which they are first presented. If the instance is referred to again later - perhaps further observations were made on the sample - then the original identifier is still used. An example for Sample Y in Dataset X which also contains Observation Z:

<http://example.com/dataset/x>
    a tern:RDFDataset ;
    sdo:hasPart
        <http://example.com/dataset/x/sample/y> ,
        <http://example.com/dataset/x/obs/z> ;
.

<http://example.com/dataset/x/sample/y>
    a tern:Sample ;
.

<http://example.com/dataset/x/obs/z>
    a tern:Observation ;
    sosa:hasFeatureOfInterest <http://example.com/dataset/x/sample/y> ;
.

Identifiers for datasets take the form https://{IRI-STEM}/{DATASET-ID} and act as a unique namespace for objects within it. If Dataset abc-123-def-456 contained Sample Y, we may have the following identifiers:

  • Dataset abc-123-def-456: https://linked.data.gov.au/dataset/abc-123-def-456

    • A unique dataset IRI issued by the Australian Government Linked Data Working Group using the https://linked.data.gov.au/dataset/ namespace

    • Other identifier issuing regimes/organisations may be used

    • Dataset X’s Namespace: https://linked.data.gov.au/dataset/abc-123-def-456/ - ending in a '/'

  • Sample Y: https://linked.data.gov.au/dataset/abc-123-def-456/sample/y

    • Uses the Dataset Namespace and a class identifier (optional) of 'sample' and an ID for the particular sample - 'y'

    • Datasets can create identifiers for their elements, within their namespace however they like

It is likely that initiatives will be created to manage data for Sites, Samples or other classes of object that ABIS knows about. If so, these initiatives might issue identifiers for those things and, if they do, those identifiers should be used. See the next section for how.

Alternate Identifiers

Many objects represented using ABIS will usefully have external identifiers recorded. One case could be samples that have museum IDs, another, datasets already listed in a catalogue that have web page URLs.

All forms of alternate identifiers may be recorded and how they are recorded and used depends on how they function.

Alternate IRIs

If an object already has an IRI identifier, and that identifier responds to Linked Data operations, it MAY be used as the primary identifier of the object.

If an object has a Linked Data IRI assigned to it AND another assigned to it within an ABIS data generation propcess, perhaps automatically, the two IRIs should be linked like this:

<{ORIGINAL-IRI}> owl:sameAs <{NEW-IRI]}>

Here the OWL predicate owl:sameAs indicates the two IRIs identify the same thing.

If an object has an IRI assigned to it that does not link to RDF data, it should be recorded in the following manner:

<{NEW-IRI]}>
    sdo:identifier "{ORIGINAL-IRI}"^^{DATATYPE} ;
    ...  # other properties
.

Here the {ORIGINAL-IRI}, since it does not act as a Linked Data IRI, is indicated as being a literal of a specified data type.

If the datatype of the {ORIGINAL-IRI} is of a known form, such as a DOI or IGSN, then that type might be found in the BDR Datatypes Register TODO: link to datatypes register and it should be used. If its type is not known or is a generic URL, the type xsd:anyURI should be used like this:

<{NEW-IRI]}>
    sdo:identifier "{ORIGINAL-IRI}"^^xsd:anyURI ;
    ...  # other properties
.
Alternate IDs - non-IRIs

Alternate identifiers for objects that are not IRIs/URLs MUST have their identifier regime indicated. For example, if Museum X issues identifiers for samples and Sample Y has an issued identifier of SAM-Y1234, then this should be given like this:

<{SAMPLE-IRI]}>
    a tern:Sample ;
    sdo:identifier "SAM-Y1234"^^ex:museum-x-id ;
    ...  # other properties
.

…​where {DATASET-IRI]} is an IRI assigned to the sample and the predicate sdo:identifier is used to give the literal identifier value of SAM-Y1234 which has the datatype ex:museum-x-id indicated.

Datatypes such as the example ex:museum-x-ids used here MUST be registered to be useful.

Note

ABIS data destined for the Biodiversity Data Repository MUST have identifier datatypes registered in the BDR Datatypes Register TODO: link to datatypes register

Multiple alternate identifiers may be given, as long as their datatypes are unique:

<{SAMPLE-IRI]}>
    a tern:Sample ;
    sdo:identifier
        "SAM-Y1234"^^ex:museum-x-id ,
        "1073/SAMY"^^ex:igsn ;
    ...  # other properties
.

5.3. Spatially

ABIS inherits its spatial modelling from GeoSPARQL, as does the TERN Ontology.

Patterns:

Feature-centric

GeoSPARQL uses a "feature-centric" method of spatial modelling which means spatial things are represented as conceptual things first - spatial features - and then a spatial projection or representation - geometry - is linked to it. This is different to some GIS systems that model spatial things as geometries first and then apply properties to them.

Basic GeoSPARQL
Figure 4. A Feature, such as a Site, can be assigned a Geometry with any one of a number of representations. ABIS prefers the Well-Known Text representation of coordinates.

The RDF data for the example above is:

PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

ex:site-x
    a tern:Site ;
    schema:name "Site X" ;
    geo:hasGeometry [
        a geo:Geometry ;
        schema:name "Geometry X1" ;
        geo:asWKT "POLYGON ((...))"^^geo:wktLiteral ;
    ] ;
.

ABIS Types of spatial objects

There are multiple classes of spatial objects in ABIS. The following are always spatial, even when their spatial values - their geometries - are unknown:

  • Observation

  • Site

  • Sample - where the sample was collected from, not where it is now

For these classes of object, we expect to see instances of them to be associated with geometries, if known.

The following classes of object are either given as spatial - a geometry is provided - or for their spatial values to be inferred from child object geometries - see Spatial Aggregation Reasoning below:

  • RDFDataset

  • Survey

A Survey might have its spatial extent recorded directly or taken to be the envelope of the locations of the Observations it contains. Similarly, an RDFDataset will either have an extent - the extent of all the data within it - given or calculated from its contained objects, which may be Sites, Sample, Survey or Observation instances, or all of them.

Qualified Geometries

This feature-centric model allows for multiple or no geometries per spatial object which can be very powerful. The figure below gives several examples of a spatial Feature with multiple Geometries that differ different ways. The pattern here is "qualification": when a Feature is assigned multiple Geometries, they must be differentiable in some way, either by having different geometry types (point, polygon etc.) or by having different roles with respect to the Feature or by each Geometry indicating a different temporal footprint. These differentiations qualify the Geometries with respect to the Feature.

Basic PROV classes and predicates
Figure 5. Spatial Features and Geometries as modelled in the GeoSPARQL ontology with subfigure A. showing a Site feature that has two geometries provided for it: a Point and a Polygon. These could respectively represent the site’s centroid and is boundary and are differentiable by geometry type. Subfigure B. shows a feature - Saint Helena Island - with two boundary polygonal geometries differentiated by role. Subfigure C. shows a time-varying feature, a cyclone, with multiple geometries differentiated by time. Data for B. is given in the ABIS repository at https://github.com/AusBIGG/abis/tree/master/examples - see the file pattern-spatiality-saint-helena-island.

Centroid & Bounding Box Reasoning

Pomingolarna site example
Figure 6. The field site 'Pomingolarna' with bounding box, boundary and centroid geometries indicated

While it is possible to supply point and polygon geometries for a spatial object’s centroid, boundary and bounding box, a centroid and a bounding box are calculable from a boundary and should not be supplied if the boundary is known: ABIS data users, such as the BDR, will calculate them as needed. This rule is listed in ABIS' Reasoning Rules section. In the image above, the bounding box and centroid have been calculated from the boundary.

If only a centroid or a bounding box is known for a spatial object, then specific predicates from GeoSPARQL - geo:centroid & geo:hasBoundingBox - should be used to indicate that this is the type of geometry known, as opposed to a boundary or a general point for a point location which are indicated with the general-purpose geo:hasGeometry predicate. The RDF data example below is the data for the image above showing the predicates in use.

PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

ex:pomingolarna
    a tern:Site ;
    schema:name "Pomingalarna Bushland Site" ;
    geo:hasCentroid [
        geo:asWKT "POINT (147.30079728418488116 -35.11304660429588154)" ;
    ] ;
    geo:hasGeometry [
        geo:asWKT "POLYGON ((147.29457671209050318 -35.10188143482372425, 147.29938609061505872 -35.10242589276990088, 147.30346952521139769 -35.10657738460949417, 147.30287969576968976 -35.10988950378206397, 147.3050575275543963 -35.11195390682797779, 147.30707655910481435 -35.11340579468444645, 147.31129610818766196 -35.11354190917099061, 147.31088776472802238 -35.11581048394672422, 147.31177250889055586 -35.11599196992878547, 147.31009376355652307 -35.11773877250610099, 147.31007107780877163 -35.11739848628973704, 147.30911827640295542 -35.11696745708234602, 147.30846038971799317 -35.11726237180319288, 147.30800667476285071 -35.11814711596572636, 147.30793861751956797 -35.12043837648921851, 147.30812010350163632 -35.12086940569660953, 147.30827890373595324 -35.12243472229186381, 147.30832427523145611 -35.12338752369767292, 147.30684970162724312 -35.12356900967972706, 147.30635061517656936 -35.12338752369767292, 147.30455844110375097 -35.12309260897682606, 147.30274358128315271 -35.12254815103064942, 147.30147317940873108 -35.12184489285017008, 147.30029352052537206 -35.12107357742642222, 147.29224008007150815 -35.11304282272033106, 147.29457671209050318 -35.10188143482372425))" ;
    ] ;
    geo:hasBoundingBox [
        geo:asWKT "POLYGON ((147.29224008007150815 -35.12356900967972706, 147.31177250889055586 -35.12356900967972706, 147.31177250889055586 -35.10188143482372425, 147.29224008007150815 -35.10188143482372425, 147.29224008007150815 -35.12356900967972706))" ;
    ] ;
.

Geometry Literals

ABIS only allows for Well-Known Text representations of geometries indicated by the geo:asWKT predicate. No other forms of geometry literal, e.g. GeoJSON, may be used.

ABIS will infer that any literal object indicated with the geo:asWKT predicate is of the datatype geo:wktLiteral and the literal typing need not be supplied. It may also be supplied so the following are treated as equivalent:

geo:asWKT "POINT (147.30079728418488116 -35.11304660429588154)" ;

geo:asWKT "POINT (147.30079728418488116 -35.11304660429588154)"geo:wktLiteral ;

This is as per a rule in the Spatial Reasoning part of the rules section.

Coordinate Reference System

All spatial data supplied according to ABIS MUST ues the WGS84 Coordinate Reference System. Systems such as GDA94, GDA202 or others MUST NOT be used.

Since spatial data formulated according to GeoSPARQL only use the Well-Known Text format - see the Geometry Literals section above - and that format defaults to WGS84, no CRS need be indicated in data: WGS84 will be assumed.

Spatial Aggregation Reasoning

ABIS contains rules that will perform spatial reasoning on data. For example, if a dataset is presented that contains a Survey which, in turn, contains a series of Observation instances with their spatial locations indicated, the spatial extent of the Survey will be taken to be at least the area containing the Observation locations. The dataset’s extent will be at least the boundary of all contained Survey instances areas. Spatial reasoning like this and other reasoning are related in ABIS' Reasoning Rules section.

The figure below shows a boundary calculated for a series of point locations. The boundary could be the extent of a Survey for Observation point locations and this type of boundary - a convex hull - is the minimum non-concave area containing all points.

Convex hull for points
Figure 7. A convex hull boundary - in green - calculated for a series of point locations - in yellow.

Feature-to-Feature relations

In addition to associating spatial Features with one or more Geometries, GeoSPARQL, and thus ABIS, allows for Feature-to-Feature (topological) spatial relations between pairs of Features to be recorded. There are multiple allowed relation families in GeoSPARQL but ABIS prefers use of the https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#simple_features_relation_family[_Simple Features relations] which are summarised as follows:

Name GeoSPARQL Predicate Meaning

equals

geo:sfEquals

The spatial extents of the two objects are exactly the same

disjoint

geo:sfDisjoint

The spatial extents of the two objects do not touch or overlap

intersects

geo:sfIntersects

The spatial extents of the two objects have at least one point in common

touches

geo:sfTouches

The spatial extents of the two objects have at least one point in common, but their interiors do not intersect (i.e. only their boundaries intersect)

within

geo:sfWithin

The spatial extent of the first object is wholly contained by the spatial extent of the second object

contains

geo:sfContains

The spatial extent of the first object wholly contains the spatial extent of the second object (i.e. the inverse of within)

overlaps

geo:sfOverlaps

The spatial extents of the two objects have some, but not all, points in common, and the dimensions of the intersection are the same as those of the objects

crosses

geo:sfCrosses

The spatial extents of the two objects have some, but not all, interior points in common and the dimensions of intersection is less than the dimensions of at least one of them (i.e. two 2-D areas' intersection is a 1-D line or two lines' intersection is a 0-D point)

The most commonly used spatial relations are contains/within and overlaps. Here are some examples of Feature-to-Feature relations for real and example Features:

PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

# Australia, according to the Australian Bureau of Statistics' ASGS Linked Data dataset
<https://linked.data.gov.au/dataset/asgsed3/AUS/AUS>
    a geo:Feature ;
    schema:name "Australia" ;
    geo:sfContains
        <https://linked.data.gov.au/dataset/asgsed3/STE/8> ,  # ACT
        <https://linked.data.gov.au/dataset/asgsed3/STE/1> ,  # NSW
        <https://linked.data.gov.au/dataset/asgsed3/STE/7> ,  # NT
        # ...
        <https://linked.data.gov.au/dataset/asgsed3/STE/2> ;  # Victoria
.

<https://linked.data.gov.au/dataset/asgsed3/STE/1>  # NSW
    a geo:Feature ;
    schema:name "New South Wales" ;
    geo:sfWithin <https://linked.data.gov.au/dataset/asgsed3/AUS/AUS> ;
.

# An example Site within NSW
ex:site-x
    a tern:Site ;
    schema:name "Site X" ;
    geo:sfWithin <https://linked.data.gov.au/dataset/asgsed3/STE/1> ;
.
# ex:site-x geo:sfWithin <https://linked.data.gov.au/dataset/asgsed3/AUS/AUS>
# can be inferred from the site being within NSW being within Australia

# NSW & Victoria touch along their common border
<https://linked.data.gov.au/dataset/asgsed3/STE/1>
    geo:sfTouches <https://linked.data.gov.au/dataset/asgsed3/STE/2> ;
.

GeoSPARQL provides function definitions for the calculation of Feature-to-Feature relations from geometry data and all compliant implementations of GeoSPARQL allow these calculations to result in declarations of equivalent predicates. So if object A is calculated as being within object B, then the RDF triple <A> geo:sfWithin <B> may be recorded.

Elevation & Depth

Absolute

If the absolute elevation or depth of an object needs representation, the 2D + Z forms of Well-Known Text representation of a geometry should be used: POINTZ, LINESTRINGZ & POLYGONZ.

For example, if Observation N was made at longitude 147.308040 E, latitude 35.121824 S at an elevation of 234 metres, POINTZ should be used like this:

PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

ex:obs-n
    a tern:Observation ;
    schema:name "Observation N" ;
    geo:hasGeometry [
        geo:asWKT "POINTZ(147.308040 -35.121824 234)" ;
    ] ;
.

Depth should be similarly indicated with a POINTZ WKT representation with the Z value given as a negative, i.e. 20m below sea level should be -20.

Relative

If relative elevation or depth needs representation, the schema.org schema:elevation & schema:depth should be used.

For example, if a Sample is obtained 3m below ground surface at longitude 147.308040 E, latitude 35.121824 S, it should be recorded like this:

PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

ex:obs-n
    a tern:Observation ;
    schema:name "Observation N" ;
    geo:hasGeometry [
        geo:asWKT "POINT(147.308040 -35.121824)" ;
    ] ;
    schema:depth [
        schema:value 3 ;
        schema:unitCode <https://qudt.org/vocab/unit/M> ;  # QUDT's IRI for metre
    ] ;
.

Elevation and depth values should use positive numbers only.

If a simple value for depth is given, e.g. ex:obs-n schema:depth 3, this will be interpreted as being in metres.

5.4. Temporality

Feature-centric

ABIS inherits its temporal modelling from the Time Ontology. The TERN Ontology uses the Time Ontology in places and used direct time representations elsewhere. This may be harmonised in the future.

ABIS uses a feature-centric approach for temporality, just as it does with spatiality. Just as per <GSP, GeoSPARQL>> where spatial objects are conceptual things with associated geometries, following OWL TIME, temporal objects are conceptual things with associated temporal "geometries" or temporal footprint.

Where for spatial objects we link a Feature to a Geometry which in turn links to a literal representation of the spatial footprint, say a Well-Known Text polygon, for temporal objects we link the temporal feature to a time:TemporalEntity, the equivlane of a temporal geometry, which is either an time:Instant or a time:Interval` which then contains dates, date/times etc.

The following code shows several example Survey instances, which are temporal features, linked to different temporal entities. The selection of particular temporal entities will come down to what is known about the Survey.

PREFIX ex: <http://example.com/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX time: <http://www.w3.org/2006/time#>

# Survey X started on the 15th of March, 1987
# and ended on the 23 of March, 1987
ex:survey-x
    a tern:Survey ;
    schema:name "Survey X" ;
    time:hasTime [
        time:hasBeginning [ time:inXSDDate "1987-03-15" ] ;
        time:hasEnd [ time:inXSDDate "1987-03-23" ] ;
    ] ;
.

# We only know Survey Y occurred in April, 2010
ex:survey-y
    a tern:Survey ;
    schema:name "Survey Y" ;
    time:hasTime [
        time:inXSDgYearMonth "2020-04"
    ] ;
.

# Survey Z is on-going or at least
# we don't know if/when it ended as only
# a beginning date is given
ex:survey-z
    a tern:Survey ;
    schema:name "Survey Z" ;
    time:hasTime [
        time:hasBeginning [ time:inXSDDateTime "2023-12-10T14:30:00" ] ;
    ] ;
.

Date & Time representations

OWL TIME allows a number of data and time literal representations for date/time instants and any may be used: use the one that best corresponds with the reality of the thing you are modelling. The code example above shows three different ones in use: xsd:date, xsd:gYearMonth and xsd:dateTime.

The following table gives a list of date/time data types and the OWL TIME predicate used to indicate them. Format values in the table below use the codes from https://strftime.org/, for example %Y is "Year with century as a decimal number" e.g. 2013, not 13.

Datatype Indicating Predicate Format Example Use

xsd:dateTimeStamp

time:inXSDDateTimeStamp

%Y-%m-%dT%H:%I:%S%z

2013-07-24T15:17:12.55+1000

To indicate a time - to the second or part of a second - with a known timezone

xsd:dateTime

time:inXSDDateTime

%Y-%m-%dT%H:%I:%S

2013-07-24T15:17:12.55

To indicate a time - to the second or part of a second - without a known timezone

xsd:date

time:inXSDDate

%Y-%m-%d

2013-07-24

To indicate a date with time unknown or irrelevant

xsd:gYearMonth

time:inXSDgYearMonth

%Y-%m

2013-07

To indicate a month in a particular year

xsd:gYear

time:inXSDgYear

%Y

2013

To indicate a year

Note that when you use the predicates listed in the table above, ABIS will infer the datatype of the object indicated by the predicate and give an error if the data cannot be parsed as that datatype. You do not need to specify the datatype but you must get the format correct.

Note

Models that ABIS inherits from sometimes include seemingly arbitrary data/time restrictions, such as SOSA requiring that a sosa:resultTime` only be used to indicate an xsd:dateTime. ABIS ignores such restrictions: you may use the date or time representation best suited to convey the real-world reality of your objects' temporality of any temporal indication predicate.

5.5. Provenance

How things derive from other things, when and where this occurs and who may be responsible for actions is the domain of the Provenance Ontology (PROV) which is one of ABIS’s Background Models.

PROV’s basic classes and the predicates that relate them to one another are given below.

Basic PROV classes and predicates
Figure 8. Basic PROV classes and predicates

Many of ABIS' models follow on from the pattern in the figure above and many figures further down in this document are coloured according to PROV’s basic classes. For example, the TERN Ontology's Sampling class is a subclass of PROV’s Activity class and instances of it may have used an instance of a Site, which is a subclass of PROV’s Entity, to have generated an instance of the class Sample which is another subclass of Entity.

The figures in the Observations & Results and the Feature of Interest patterns use this colouring.

PROV’s provenance reasoning is also applicable to parts of ABIS. For example, the Projects Model indicates that instances of its Project class, which is a subclass of PROV’s Activity, can have generated instances of the TERN Ontology's RDFDataset class, which is a subclass of PROV’s Entity, and may have been associated with an Agent - an Organisation or Person. If so, then the resulting RDFDataset instances will be able to have an attributional relationship to the Agent instance calculated. This is shown in the figure below.

PROV-style reasoning
Figure 9. PROV-style reasoning using facts given in the Projects Model

5.6. Agents

Agents - things with agency to do work such as Organisations, People, Groups (of orgs and people) and perhaps software systems - are modelled in many Semantic Web and Knowledge Graph systems. In ABIS, we follow the general pattern for Agents outlined in the Provenance Ontology (PROV): see the section above.

In addition to the simple and direct kind of relationship between Agents and data (Entities) show above in Figure 8 where an Entity can be attributed to an Agent, we use a nuanced version of that was attributed to relationship, qualified attribution, which is also defined in PROV. qualified attribution is a type of qualified relation which means it related two things together with qualifying facts. While these qualifying facts can be anything, in ABIS, the expected qualifier is a role: a role that the Agent plays with respect to the Entity. For example, for a dataset, one Agetn might be the author of the data, another the publisher. This could be modelled as in Figure 10, below.

PROV-style reasoning
Figure 10. Two Agents related to a single dataset Entity with different roles using the qualified attribution predicate from PROV

The roles that can be used for attributional qualification in ABIS are open-ended - new ones can be defined - but they are controlled - they must be proposed and accepted into a vocab to be legitimate. The vocab ABIS uses for these roles is the IDN Role Codes vocabulary - see the Vocabularies Listing. It contains concepts such as author, publisher, collaborator and funder.

5.7. Observations & Results

This pattern is inherited from the TERN Ontology, which, in turn, inherits it from SOSA.

The result of any observation in ABIS is a numerical or classification value for an observed property of a feature of interest (see next pattern).

The observation act is a temporal activity which, recorded or not, follows some procedure.

The value may be qualified with units of measure and uncertainty.

ABIS Parts
Figure 11. Two styles of Result: a numerical and a classification

Using this pattern, the thing that ties the result value to the property of the thing observed is the observation.

NOTE

Since observations record when a result was produced, multiple observations of the property of a thing can be recorded over time, such as multiple estimations of the taxon of a specimen.

5.8. Feature of Interest

A feature of interest is the object of some activity’s focus. This is a relative term: when an observation considers the property of something - perhaps the colour of a part of a leaf - then the part leaf only - a sample of it - is the feature of interest. If the observation were to consider the colour of the whole leaf, then the leaf is the feature of interest. If the colour of the whole bush from which the leaf came was considered, then the whole bush is the feature of interest.

If the average colour of a whole area of bushland was considered, the feature of interest would be the whole area, not any single bush or plant within it.

ABIS Parts
Figure 12. Three Features if Interest indicated with respect to the Observation that is observing properties of them. Whether something is a sample of something else doesn’t affect its status as a Feature of Interest with respect to an Observation.

5.9. Site hierarchy and types

6. Models

As per the Multiple Models section within the Introduction, ABIS is a set of models. The models have different roles and a dependency hierarchy.

6.1. Model Roles

The roles played by the various models within ABIS are:

6.2. Model Dependency Hierarchy

The dependency hierarchy indicates which models profile other models and thus are dependent on them. The mechanism of profiling are as per the Profiles Vocabulary but can easily be summarised as:

Any data which conforms to a model MUST conform to any models it profiles
— Profiles Vocabulary

In practice this means that any model profiling any other may use elements from that profiled model but must not break any rules imposed on that element’s use by the profiled model. These rules usually take the forms of required predicates and values for instances of particular classes, categorisation of object with terms from vocabularies and so on.

The following figure depicts the profiling relationships between the various models within ABIS.

ABIS Parts
Figure 13. The profile hierarchy of the models within ABIS. All the arrows indicate dependency or, formally, prof:isProfileOf relationships between the models, shown as rectangles. The ABIS model itself is the union of the NSL Model, the TERN Ontology and the ABIS Component Models.

6.3. Foreground Model

The ABIS Foreground Model is the union of the NSL Model, the TERN Ontology and the ABIS Component Models, as shown in Figure 7, above.

When modelling biodiversity observations - ABIS' main concern - ABIS uses the TERN Ontology. When modelling taxonomic name objects, ABIS uses the NSL Model. When project information and data release details are modelled, the ABIS Projects & ABIS Data Release models are used.

6.4. Component Models

The Component Models of ABIS are:

6.4.1. TERN Ontology

The TERN Ontology is a re-skinned, and slightly extended, version of the Sensor, Observations, Sampling & Actuation (SOSA) ontology to better cater for the biodiversity community.

The main patterns within the TERN Ontology are for observation and sampling. The observation patterns are inherited directly from SOSA and are essentially as per the following figure.

TERN’s Observation pattern
Figure 14. Classes and predicates from the SOSA ontology used directly within the TERN Ontology.

This pattern sees instances of the class Observation - individual acts of a person or a sensor observing something - following procedures to observe properties of a Feature Of Interest which could be a surveyed site, a material sample or even a satellite images (which would, in turn, be a sample of the land imaged). Observation instances produce Result instances which contain categorisations, numerical values, units of measure and so on, as necessary to well characterise the observed property quantity or category.

The Provenance Ontology offers a generic perspective on observation and sampling with its take on the observation pattern above given in the figure below. This is as per the Provenance Pattern described in the Patterns Section.

PROV interpretation of observation
Figure 15. The PROV perspective on the classes and predicates in the TERN Ontology’s Observation pattern

The TERN Ontology’s sampling pattern follows SOSA too but uses specialised classes for Site, Survey and other things familiar to those who have undertaken biodiversity surveys in the field. The general pattern is as the figure below.

TERN’s Observation pattern
Figure 16. Classes and predicates within the TERN Ontology used to characterise sampling. The is sample of predicate can be derived from relations between a Sample, the Sampling and the Site. Note the similarity of structure to the SOSA Observation pattern.

TERN Ontology data is packaged into instances of the TERN Ontology’s RDFDataset class like this:

ex:dataset-x
    a tern:RDFDataset ;
    # ... dataset metadata
.

ex:sample-y
    a tern:Sample ;
    # ...
    void:inDataset ex:dataset-x ;
.

ex:obs-z
    a tern:Observation ;
    # ...
    void:inDataset ex:dataset-x ;
    sosa:hasFeatureOfInterest ex:sample-y ;
.
6.4.1.1. Examples

See Annex C: TERN Ontology Examples for a full example of TERN Ontology data with explanations for each part.

Also see the ABIS Portal for multiple examples that can be loaded and validated using the online validators also there.

6.4.1.2. Further Information

Further details of the TERN Ontology’s classes, predicates and patterns of expected use are documented at:

6.4.2. NSL Model

An overview of the main classes and predicates of the NSL Model is given in the figure below.

NSL Model Overview
Figure 17. An overview of the National Species List (NSL) model in Semantic Web form, adapted from that model’s documentation online at https://linked.data.gov.au/def/nsl

The NSL Model associates the class Taxon representing "A group of organisms considered by taxonomists to form a homogeneous unit" with names for them - Taxon Name - and usage of that name in literature - instances of the class Usage, which is a special type of BibliographicReference that quotes the Taxon Name as used in a CreativeWork. It also allows the citation of Usage instances bu other Usage instances.

The join point between the NSL Model and the TERN Ontology is on the Result of an Observation being the assignment of a Taxon Name to a Feature of Interest (probably a Sample) as per the figure below:

NSL Model Overview
Figure 18. An overview of the National Species List (NSL) model in Semantic Web form, adapted from that model’s documentation online at https://linked.data.gov.au/def/nsl
Note

The NSL Model stated that a Taxon, rather than a Taxon Name, MAY be assigned to a Feature of Interest, but it sets criteria for this in its ABIS Mapping section.

6.4.3. Projects Model

ABIS contains a simple model of Projects where a Project is defined as "An Activity that requires concerted effort following a Plan in pursuit of an objective". The Model is fully described in Annex A: Projects Model.

The following figure illustrates the basic relationships of the class Project and Program, the only other class defined by the model.

Projects Model Class Hierarchy
Figure 19. The two classes defined by the Projects Model - Project & Program - and their main relationships.

The join point between the Projects Model and the rest of ABIS is that datasets of ABIS data - instances of the RDFDataset class - are produced by instances of Project as per the figure below.

Projects Model Join Poin
Figure 20. The Projects Model joins the rest of ABIS by Project instances producing RDFDataset instances.

See Annex A for more details about the Project Model.

6.4.4. Data Release Model

ABIS contains a simple model for describing aspects of data release: to whom, under what circumstances and when data may be released. The Model is fully described in Annex B: Data Release Model.

The following figure illustrates the basic elements of this model.

Overview of the Data Release Model
Figure 21. An overview of the Data Release Model

The Data Release Model defines predicates - embargoed until & embargo period - which can be applied to instances of the RDFDataset class which set absolute or relative embargo release times. The model details the relations between these predicates.

6.5. Background Models

The Background Models within ABIS are all those profiled by the Component Models. They are shown visually in the Model Dependency Hierarchy, above.

The main Background Models for ABIS are:

Of these models, all provide Semantic Web rules that can be used for data validation except for Darwin Core. Validators for each of these models, other than Darwin Core, are given in the Validation Section. These validators may be used individually or combined, within the ABIS Validator.

These models in turn profile several fundamental Semantic Web models:

Neither these models nor ABIS provide validators, however syntactic and some semantic data validation for RDF, RDFS & OWL data is built in to many Semantic Web / Linked Data tooling and, for example, syntactically invalid RDF data will not be able to be processed by ABIS other validators.

Additional Background Models - the Profiles Vocabulary & Olis - are used to describe the relationships between ABIS models and between units of ABIS data within datasets, respectively, and do not need to be directly considered by users of ABIS: their impact is felt within the descriptions of this specification document itself.

Specific details of all these Background Models are not directly given here, other than certain patterns they impose and these are presented in the Patterns Section.

7. Vocabularies

ABIS use depends on the selection of concepts from many vocabularies. For example, the observed growth stage of a plant may be indicated by use of Dead, Regrowth or Senescence taken from TERN's Growth Stage vocabulary.

Some uses of ABIS, such as for the submission of data to the BDR, required the use of particular vocabularies. Mandates for particular vocabulary use are indicated by individual profiles of ABIS - see Profiles.

Some Component Models of ABIS also require the use of particular vocabularies, for example, the Projects Model mandates that roles chosen for an attribution’s hadRole predicate, when used for an instances of the abis:Project class must come from the IDN Role Codes Vocabulary

The next section lists vocabularies know to be used with ABIS.

7.1. Listing

Here is a list of vocabularies known to be either required or suggested for use with ABIS and the locations in which they are used (which predicates are expected to indicate concepts from them).

Vocabulary Domain Where Used

BDR Datatypes Register

Identifiers for data types which, in RDF, are literal data values. Simple datatypes are things like string, date, integer etc. The BDR maintains a list of custom datatypes in this vocabulary to allow the interpretation of strings as identifiers from particular systems

RDF datatypes values

Use further described below

IDN Role Codes Vocabulary

Roles that Agent instances play with respect to proscribed subclassses of Activity via Association instances

Projects Model, range value for the predicate prov:hadRole when used on Association or Attribution instances when linked to an Project or Program instances

Incomplete

7.1.1. BDR Datatypes Register

The BDR maintains a list of datatypes used to indicate systems and regimes that create identifiers for data and which is presented as a vocabulary at the BDR Vocabs Page. These datatypes are used with ABIS RDF data to indicate which system/regime created a literal datatype value.

For example, the Western Australian Museum creates numbers - "WAM Numbers" - for specimens abd this Register identifies the WAM Number system as dt:WAMNumber.

If Specimen X has a WAM Number of 55 and an IRI assigned by some RDF creation system of https://linked.data.gov.au/dataset/bdr/sample/316c92f0-d918-4648-a964-3e4066d767ed, then the Sample can have the WAM Number associated with it like this:

PREFIX dt: <https://linked.data.gov.au/dataset/bdr/datatypes/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

<https://linked.data.gov.au/dataset/bdr/sample/316c92f0-d918-4648-a964-3e4066d767ed>
    a tern:Sample ;
    schema:name "Specimen X" ;
    schema:identifier "55"^^dt:WAMNumber ;
.

Incomplete

8. Profiles

ABIS is a multi-part model that profiles many other models - see the Model Dependency Hierarchy section for details.

Likewise, profiles of ABIS are made to constrain and/or extend its use.

Profile makers are able to define extended constraints on the use of ABIS to meet particular business needs. This can include constraining value ranges, vocabularies used and so on. Profile rules are entirely a matter for profile defines however data validated according to a profile of a standard, must always be valid according to the standard itself.

8.1. Profiles of ABIS

Profiles of ABIS may be defined anywhere however profile creators are encouraged to list their profiles here by contacting ABIS' maintainers.

The following profiles of ABIS are known to exist:

8.2. BDR Profile

This profile defines the requirements for data to be absorbed into the Biodiversity Data Repository.

Resources

The resources within this profile are listed below. The roles given for each are taken from The Profiles Vocabulary [PROF].

Resource Role IRI Description

Specification

Specification

https://linked.data.gov.au/def/abis/bdr

The BDR Profile of ABIS (this section)

Machine-readable Profile Definition

Profile Definition

https://linked.data.gov.au/def/abis/bdr.ttl

The machine-readable definition of this Profile, as per this text, but in RDF, according to The Profiles Vocabulary [PROF]

Validator

Validation

https://linked.data.gov.au/def/abis/bdr/validator

A SHACL file used to validate RDF data according to this Profile’s rules

Data Expander

Script

https://linked.data.gov.au/def/abis/bdr/expander

A SHACL SHACL file used to expand RDF data according to this Specification’s rules

Combined Validator & Expander

Validation

https://linked.data.gov.au/def/abis/bdr/validator-combined

The combined validator and data expander SHACL file

Note

This profile’s validators are pre-loaded in the ABIS Portal.

Specification

The following subsections contain the rules of this Profile and form this Profile’s normative specification.

Model Element Mandates

The following table lists the requirements for the presence of classes and predicates assigned to data supplied according to this Profile. These requirements are in addition to those imposed by ABIS Component models, such as the TERN Ontology.

A cardinality of 1 means mandatory. 0+ means zero or more, 1+ one more, etc. 0-1 means zero or one only.

Class Predicate Cardinality Notes

Validators

Validators

Examples

Examples

9. Validation

TODO: write this section

Pinch from Geochem Spec

10. Mappings

TODO: write this section

11. Reasoning Rules

This section contains rules that ABIS-compliant systems must implement. The rules result in the creation of new data based on logical, ontological, spatial and other reasoning.

For example,

Spatial Reasoning

The following spatial reasoning rules will be applied to ABIS data.

Centroids and Bounding Boxes from Boundaries

Datasets containment of Surveys

Surveys containment of Observations

Inference of geometry literal datatypes from GeoSPARQL predicates

Temporal Reasoning

Inference of date/time literal datatypes from TIME predicates

TODO: complete this section

12. References

BIRO

Di Iorio, A., Nuzzolese, A. G., Peroni, S., Shotton, D., Vitali, F. Describing bibliographic references in RDF. In Garcia Castro, A., Lange, C., Lord, P., Stevens, R. (Eds.), Proceedings of 4th Workshop on Semantic Publishing (SePublica 2014), CEUR Workshop Proceedings 1155. Aachen, Germany: CEUR-WS.org. http://ceur-ws.org/Vol-1155/paper-05.pdf (Open Access). Ontology description online at http://www.sparontologies.net/ontologies/biro

DWC

Darwin Core Maintenance Group, Darwin Core, Biodiversity Information Standards (TDWG), Technical Specification (2009). http://www.tdwg.org/standards/450

GSP

Open Geospatial Consortium, OGC GeoSPARQL - A Geographic Query Language for RDF Data, OGC Implementation Standard. Car, N. J., & Homburg, T. (eds.) (2011). http://www.opengis.net/doc/IS/geosparql/1.1

ISO19156

International Organization for Standardization, ISO 19156: Geographic information — Observations and measurements (2011)

JSON-LD

World Wide Web Consortium, JSON-LD 1.1: A JSON-based Serialization for Linked Data, W3C Recommendation (16 July 2020). https://www.w3.org/TR/json-ld11/

NSLM

Centre for Australian National Biodiversity Research (CANBR), National Species List - Semantic Web Model (2023). https://linked.data.gov.au/def/nsl

OLIS

KurrawongAI, Olis Ontology, Semantic Web Model (2022). https://olis.dev/ont

OWL2

World Wide Web Consortium, OWL 2 Web Ontology Language Document Overview (Second Edition), W3C Recommendation (11 December 2012). https://www.w3.org/TR/owl2-overview/

PROF

World Wide Web Consortium, The Profiles Vocabulary, W3C Working Group Note (18 December 2019). https://www.w3.org/TR/dx-prof/

PROV

World Wide Web Consortium, PROV-O: The PROV Ontology, W3C Recommendation (30 February 2013). https://www.w3.org/TR/prov-o/

RDFSPEC

World Wide Web Consortium, RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation (25 February 2014). https://www.w3.org/TR/rdf11-concepts/

RDFSSPEC

World Wide Web Consortium, RDF Schema 1.1, W3C Recommendation (25 February 2014). https://www.w3.org/TR/rdf11-schema/

SDO

schema.org Consortium, schema.org, OWL vocabulary (26 June 2023). https://schema.org/

SHACL

World Wide Web Consortium, Shapes Constraint Language (SHACL), W3C Recommendation (20 July 2017). https://www.w3.org/TR/shacl/

SKOS

World Wide Web Consortium, SKOS Simple Knowledge Organization System Reference, W3C Recommendation (18 August 2009). https://www.w3.org/TR/skos-reference/

SOSA

World Wide Web Consortium, Sensor, Observation, Sample, and Actuator ontology, within Semantic Sensor Network Ontology, W3C Recommendation (19 October 2017). https://www.w3.org/TR/vocab-ssn/

TERN Ontology

Terrestrial Ecosystems Research Network (TERN). TERN Ontology. A information model to represent plot-based ecological surveys. https://linkeddata.tern.org.au/information-models/tern-ontology

TIME

World Wide Web Consortium, Time Ontology in OWL, W3C Candidate Recommendation (26 March 2020). https://www.w3.org/TR/owl-time/

TURTLE

World Wide Web Consortium, RDF 1.1 Turtle - Terse RDF Triple Language, W3C Recommendation (25 February 2014). https://www.w3.org/TR/turtle/

[VOID]

DERI, Vocabulary of Interlinked Datasets (VoID), OWL vocabulary (2010). http://vocab.deri.ie/void

XSD2

World Wide Web Consortium, XML Schema Part 2: Datatypes (Second Edition), W3C Recommendation (28 October 2004). https://www.w3.org/TR/xmlschema-2/

Annex A: Projects Model

Projects Model Class Hierarchy
Figure 22. The two classes defined by the Projects Model - Project & Program - and their main relationships.

Projects are part of Programs and both are specialised forms of PROV's Activity class. An Activity is "something that occurs over a period of time and acts upon or with entities" which means Project`s & `Program`s can have all the properties that `Activities can have, such as temporal extents, Agents that have causal relationships to them and so on.

Metadata

IRI

https://linked.data.gov.au/def/abis/projects

Name

ABIS Data Release Model

Definition

This model is for describing Projects where Project is defined as "An Activity that requires concerted effort following a Plan in pursuit of an objective".

Created Date

2023-10-15

Modified Date

2023-12-28

Issued Date

2023-12-28

Version

1.0

Version IRI

abisp:1.0

Version History

2.0 - 2023 Dec - First release (v2.0 to match ABIS)

Creator

the Department of Climate Change, Energy and the Environment (DCCEEW)

Owner

Australian Biodiversity Information Governance Group (AUSBIGG)

Publisher

Department of Climate Change, Energy and the Environment (DCCEEW)

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Contacts

AusBIGG is supported by DCCEEW’s' Biodiversity Data Repository (BDR) Team. Contact the BDR Team on bdr@dcceew.gov.au
Issue tracking of the ABIS standard is managed online at https://github.com/AusBIGG/abis/issues

Code Repository

https://github.com/AusBIGG/abis

Classes

Class Index

Classes defined here:

Classes defined elsewhere:

Project

Projects Model Project Class
Figure 23. The Projects Model Project Class and its expected predicates
Property Value

IRI

abis:Project

Subclass of

Activity

Is Defined By

This model

Preferred Label

Project

Definition

An Activity that requires concerted effort following a Plan in pursuit of an objective

History Note

Defined by BDR Team in 2023 in response to BDR usage needs

Expected Properties

is part of, has time, has geometry, generated,

Example

:project-m
    a abis:Project ;
    sdo:name "Project M" ;
    sdo:description "South Australian government Project M-23" ;
    abis:purpose "To determine extent of koala populations in NE SA" ;
    sdo:keywords
        ex:koala ,
        <https://linked.data.gov.au/dataset/asgsed3/STE/4> ;   # S.A.
    sdo:isPartOf :program-n ;
    # Note TIME/PROV at https://www.w3.org/TR/owl-time/#time-prov
    # Note temporal range within that of containing Program
    prov:startedAtTime "2023-12-01"^^xsd:date ;
    prov:endedAtTime "2023-12-15"^^xsd:date ;
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "POLYGON ((138.010254 -26.007424, 140.976563 -25.99755, ..., 138.010254 -26.007424))"
    ] ;
    prov:qualifiedAttribution [
        prov:agent ex:dewr ;  # SA Dept Env, e.g. only
        prov:hadRole role:principalInvestigator ;
    ] ;
    prov:generated ex:dataset-x ;
.

:program-n
    a abis:Program ;
    sdo:name "Program N" ;
    sdo:hasPart :project-m ;
    # Note TIME/PROV at https://www.w3.org/TR/owl-time/#time-prov
    time:hasTime [
        time:hasBeginning [
            time:inXSDDateTime "2023-12-01"^^xsd:date ;
        ] ;
        time:hasEnd [
            time:inXSDDateTime "2023-12-28"^^xsd:date ;
        ] ;
    ] ;
    # ... other properties
.

Program

Projects Model Program Class
Figure 24. The Projects Model Program Class and its expected predicates
Property Value

IRI

abis:Project

Subclass of

Activity

Is Defined By

This model

Preferred Label

Project

Definition

An Activity that requires concerted effort following a Plan in pursuit of an objective

History Note

Defined by BDR Team in 2023 in response to BDR usage needs

Expected Properties

has part and all the properties of Project, other than is part of

Example

See the example for Project

Attribution

Property Value

IRI

prov:Attribution

Preferred Label

Attribution

Definition

The ascribing of an entity to an agent

Scope Note

Use objects of this class to link Project or Program objects to Agent objects and the roles they played with respect to the Activity

Is Defined By

PROV

Expected Properties

agent, had role

Example

See the Example for Project: the range value for the prov:agent predicate of the Dataset

Agent

Property Value

IRI

prov:Agent

Preferred Label

Agent

Definition

Something that bears some form of responsibility for an activity taking place

Scope Note

Use specialised objects of this class - Organisation or Person - that bear some form of responsibility for a Project where their role is qualified within a Attribution

Is Defined By

PROV

Expected Properties

None: use the Agent’s identifier only

Example

See the Example for Project

Organization

Property Value

IRI

abis:Project

Subclass of

Activity

Is Defined By

This model

Preferred Label

Project

Definition

An organization such as a school, NGO, corporation, club, etc.

History Note

Defined by schema.org

Expected Properties

Example

See the Example for Project

Person

Property Value

IRI

prov:Agent

Preferred Label

Agent

Definition

Something that bears some form of responsibility for an activity taking place

Scope Note

Use specialised objects of this class - Organisation or Person - that bear some form of responsibility for a Project where their role is qualified within a Attribution

Is Defined By

PROV

Expected Properties

None: use the Agent’s identifier only

Example

See the Example for Project

Concept

Property Value

IRI

skos:Concept

Preferred Label

Concept

Definition

An idea or notion; a unit of thought

Scope Note

Direct use of this Class is not expected, instead where a Concept is indicated for use, a specific concept from a controlled vocabulary is expected to be used.

Is Defined By

SKOS

Expected Properties

None

Predicates

This model defines only one predicate - purpose - but also requires the use of others defined elsewhere. Definitions for all predicates are copied from source and given here.

Predicate Index

Predicates defined here:

Predicates defined elsewhere:

purpose

Property Value

IRI

abis:purpose

Preferred Label

purpose

Definition

The intent of the Activity

Scope Note

Use this predicate to indicate a textual intent for a Project or a Program

Is Defined By

This model

Example

See the example for Project

name

Property Value

IRI

sdo:name

Preferred Label

name

Definition

The name of the item

Scope Note

Use this predicate to indicate a textual name for something

Is Defined By

SDO

Example

See the example for Project

description

Property Value

IRI

sdo:description

Preferred Label

description

Definition

A description of the item

Scope Note

Use this predicate to indicate a textual description for something

Is Defined By

SDO

Example

See the example for Project

keywords

Property Value

IRI

sdo:keywords

Preferred Label

keywords

Definition

Keywords or tags used to describe some item

Scope Note

Use this predicate to indicate Concept instances from controlled vocabularies to categorise the object this predicate is applied to

Is Defined By

SDO

Example

See the Example for Project

has part

Property Value

IRI

sdo:hasPart

Preferred Label

has part

Definition

Indicates an item is part of this item

Inverse of

is part of

Scope Note

Use this predicate to indicate that a Program includes a See the example for Project

Is Defined By

SDO

Example

See the example for Project

is part of

Property Value

IRI

sdo:isPartOf

Preferred Label

is part of

Definition

Indicates an item that this item, in some sense, is part of

Inverse of

has part

Scope Note

Use this predicate to indicate that a Program includes a See the example for Project

Is Defined By

SDO

Example

See the example for Project

has time

Property Value

IRI

time:hasTime

Preferred Label

has time

Definition

Supports the association of a temporal entity (instant or interval) to any thing

Scope Note

Use this predicate to indicate that a Program or a Project has a temporal region of concern

Is Defined By

OWL TIME

Example

See the example for Project

hasGeometry

Property Value

IRI

geo:hasGeometry

Preferred Label

is part of

Definition

A spatial representation for a given Feature

Scope Note

Use this predicate to indicate that a Program or a Project has a spatial area of concern

Is Defined By

GeoSPARQL

Range

Geometry

Example

See the example for Project

qualified attribution

Property Value

IRI

prov:qualifiedAttribution

Preferred Label

qualified attribution

Definition

The ascribing of an entity to an agent

Scope Note

Use this predicate to link a Project or a Program to a Attribution which then links to an Agent, which must be an Organization or a Person, and a Concept

Is Defined By

PROV

Example

See the example for Project

agent

Property Value

IRI

prov:agent

Preferred Label

agent

Definition

References an Agent which influenced a resource

Scope Note

Use this predicate to link an Project or a Program to an Agent, which must be an Organization or a Person

Is Defined By

PROV

Example

See the example for Project

had role

Property Value

IRI

prov:hadRole

Preferred Label

had role

Definition

A role is the function of an entity or agent with respect to an activity

Scope Note

Use this predicate to link an Project or a Program to a Concept

Is Defined By

PROV

Example

See the example for Project

generated

Property Value

IRI

prov:generated

Preferred Label

generated

Definition

Generation is the completion of production of a new entity by an activity

Scope Note

Use this predicate to link a Project or a Program to data that it produced, in the form of an RDFDataset containing ABIS data

Is Defined By

PROV

Example

See the example for Project

Shapes

The following SHACL shapes are graph patterns mandated by this model.

Shapes Index

INCOMPLETE

IDN Roles

Property Value

IRI

abis:idn-roles

Preferred Label

IDN Roles

Definition

Roles for the predicate prov:role on instances of prov:Attribution linked to an abis:Project must be taken from the IDN Role Codes Vocabulary

Is Defined By

This model’s validator

Code

abis:idn-roles
    a shacl:Shape ;
    sdo:name "IDN Roles" ;
    sdo:description "Roles for the predicate prov:role on instances of prov:Attribution linked to an abis:Project must be taken from the IDN Role Codes Vocabulary (https://data.idnau.org/pid/vocab/idn-role-codes)" ;
    sh:path [

    ] ;
.

INCOMPLETE

Annex B: Data Release Model

Overview of the Data Release Model
Figure 25. An overview of the Data Release Model

This model is for describing aspects of data release: to whom, under what circumstances and when data may be released.

Note

Currently, the Data Release model only handles data embargos, but it is likely to be expanded as data release/restriction concerns are found to be important within the ABIS community. Please communicate any data release modelling issues to the BDR Team using the "Contacts" details.

Metadata

IRI

https://linked.data.gov.au/def/abis/data-release

Name

ABIS Data Release Model

Definition

This model is for describing aspects of data release: to whom, under what circumstances and when data may be released.

Created Date

2023-10-15

Modified Date

2023-12-28

Issued Date

2023-12-28

Version

1.0

Version IRI

abisdr:2.0

Version History

2.0 - 2023 Dec - First release (v2.0 to match ABIS)

Creator

the Department of Climate Change, Energy and the Environment (DCCEEW)

Owner

Australian Biodiversity Information Governance Group (AUSBIGG)

Publisher

Department of Climate Change, Energy and the Environment (DCCEEW)

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Contacts

AusBIGG is supported by DCCEEW’s' Biodiversity Data Repository (BDR) Team. Contact the BDR Team on bdr@dcceew.gov.au
Issue tracking of the ABIS standard is managed online at https://github.com/AusBIGG/abis/issues

Code Repository

https://github.com/AusBIGG/abis

Classes

This model defines none of its own classes and only indicates the TERN Ontology's RDFDataset class for use with the predicates it does define.

Predicates

embargoed until

Property Value

IRI

abis:embargoedUntil

Preferred Label

embargoed until

Definition

A date after which the is no longer embargoed

Is Defined By

This model

Domain

RDFDataset

Range

xsd:date, xsd:dateTime or xsd:dateTimeStamp

Scope Note

The embargo period is understood to cease on the time instance of the start of the object value, e.g. at 00:00:00 (midnight) of a given date, or midnight of the first day of a given month.

Example

# Dataset X is embargoed until the 5th of May, 2024

:dataset-x
    a tern:RDFDataset ;
    sdo:name "Dataset X" ;
    dcterms:embargoedUntil "2024-05-11"^^xsd:date ;
    # ... other dataset properties
.

# Dataset Y is embargoed until 2025

:dataset-y
    a tern:RDFDataset ;
    sdo:name "Dataset Y" ;
    dcterms:embargoedUntil "2025-01-01"^^xsd:date ;
    # ... other dataset properties
.

embargo period

Property Value

IRI

abis:embargoPeriod

Preferred Label

embargo period

Definition

A temporal duration within which the object is embargoed

Is Defined By

This model

Domain

RDFDataset

Range

time:TemporalDuration

Scope Note

This predicate can only be used if the start of the embargo period’s duration can be established by a business or system rule. If it cannot, use embargoed until instead, with a fixed date.

Example

# Dataset X is embargoed for a period of 3 months, calculated to start
# from the issued date.
# The calculation is defined by a business rule which is not
# expressable in RDF

:dataset-x
    a tern:RDFDataset ;
    sdo:name "Dataset X" ;
    dcterms:issued "2023-12-25"^^xsd:date ;
    abis:embargoPeriod [
        a time:DurationDescription ;
        time:months 3 ;
    ] ;
    # ... other dataset properties
.

Annex C: TERN Ontology Examples

This following examples are all RDF data in the Turtle format.

C1. Validating

All these examples are loaded into the ABIS Portal and may be validated online using the TERN Ontology validator which is also loaded there.

To validate these examples locally - on your own computer - you will need a validation tool installed - see the Validation Section, the example data file, the TERN Ontology validator and the TERN Ontology itself. These files are all available from this ABIS repository:

File Location Validity

TERN Ontology Validator

https://github.com/AusBIGG/abis/tree/master/validators/tern-validator.ttl

-

TERN Ontology Model

https://github.com/AusBIGG/abis/tree/master/models/components/tern-model.ttl

-

Example 01 data

https://github.com/AusBIGG/abis/tree/master/examples/tern-eg-01.ttl

valid

Example 02 data

https://github.com/AusBIGG/abis/tree/master/examples/tern-eg-02.ttl

invalid

If using the pySHACL tool, the following command will validate the data using the files above:

pyshaclz -s tern-validator.ttl -e tern-ont.ttl tern-eg-01.ttl -f table

C2. Example 01 - valid

This example is valid according to the TERN Ontology validator.

TERN Ontology example 01 - valid
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX ex: <http://example.com/thing/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX sosa: <http://www.w3.org/ns/sosa/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX time: <http://www.w3.org/2006/time#>
PREFIX void: <http://rdfs.org/ns/void#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

ex:dataset-01
    a tern:RDFDataset ;
    dcterms:description "A minimally valid tern:RDFDataset instance" ;
    dcterms:issued "2021-11-18"^^xsd:date ;
    dcterms:title "TERN RDFDataset 01" ;
.

ex:obs-01
    a tern:Observation ;
    rdfs:label "TERN Observation 01" ;
    void:inDataset ex:dataset-01 ;
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "POINT(143, -27)"^^geo:wktLiteral
    ] ;
    rdfs:comment "A minimally valid tern:Observation instance" ;
    sosa:hasFeatureOfInterest ex:foi-01 ;
    sosa:hasResult [
        a tern:Float ;
        rdf:value "42"^^xsd:double ;
        tern:uncertainty "0.5"^^xsd:double ;
    ] ;
    sosa:hasSimpleResult "42"@en ;
    sosa:observedProperty <https://example.org/op/1> ;
    sosa:phenomenonTime [
        a time:Instant ;
        time:inXSDDateTimeStamp "2021-11-18T14:35+10:00"^^xsd:dateTimeStamp ;
    ] ;
    sosa:usedProcedure <https://example.org/proc/1> ;
    tern:resultDateTime "2021-11-18T14:35:00"^^xsd:dateTime ;
.

ex:foi-01
    a tern:FeatureOfInterest ;
    rdfs:label "TERN FeatureOfInterest 01" ;
    void:inDataset ex:dataset-01 ;
    tern:featureType <https://example.org/ft/1> ;
.

C3. Example 02 - invalid

This example is the same data as the above but with several lines commented out (starting with #) which makes it invalid according to the TERN Ontology validator.

TERN Ontology example 02 - invalid
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX ex: <http://example.com/thing/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX sosa: <http://www.w3.org/ns/sosa/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX time: <http://www.w3.org/2006/time#>
PREFIX void: <http://rdfs.org/ns/void#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

ex:dataset-01
    a tern:RDFDataset ;
    dcterms:description "A minimally valid tern:RDFDataset instance" ;
    dcterms:issued "2021-11-18"^^xsd:date ;
    dcterms:title "TERN RDFDataset 01" ;
.

ex:obs-01
    a tern:Observation ;
    rdfs:label "TERN Observation 01" ;
    void:inDataset ex:dataset-01 ;
#    geo:hasGeometry [
#        a geo:Geometry ;
#        geo:asWKT "POINT(143, -27)"^^geo:wktLiteral
#    ] ;
    rdfs:comment "A minimally valid tern:Observation instance" ;
    sosa:hasFeatureOfInterest ex:foi-01 ;
    sosa:hasResult [
        a tern:Float ;
        rdf:value "42"^^xsd:double ;
        tern:uncertainty "0.5"^^xsd:double ;
    ] ;
    sosa:hasSimpleResult "42" ;
    sosa:observedProperty <https://example.org/op/1> ;
    sosa:phenomenonTime [
        a time:Instant ;
        time:inXSDDateTimeStamp "2021-11-18T14:35+10:00"^^xsd:dateTimeStamp ;
    ] ;
    sosa:usedProcedure <https://example.org/proc/1> ;
    tern:resultDateTime "2021-11-18T14:35:00" ;  # ^^xsd:dateTime ;
.

ex:foi-01
    a tern:FeatureOfInterest ;
    rdfs:label "TERN FeatureOfInterest 01" ;
#    void:inDataset ex:dataset-01 ;
    tern:featureType <https://example.org/ft/1> ;
.

Results from validating this example should indicate two Violations:

  1. The datatype for the value indicated by the tern:resultDateTime predicate on the object ex:obs-01 is of an invalid datatype

    • no datatype is given, so a string (xsd:string) is presumed but it should be an xsd:date, xsd:dateTime or xsd:dateTimeStamp

  2. ex:obs-01 is missing a geo:hasGeometry predicate

  3. ex:foi-01 is missing a void:inDataset predicate