1. Metadata
Australian Biodiversity Information Standard |
|
This document is the normative specification of the Australian Biodiversity Information Standard (ABIS) and includes its authoritative statements on parts, requirements and patterns. |
|
2021-10-24 |
|
2024-01-03 |
|
2023-12-04 |
|
2.1 |
|
2.1 - 2024 Jan - Implementation of ABIS Projects Model and ABIS Data Release Model within ABIS |
|
Originally Department of Agriculture, Water and the Environment (DAWE), |
|
Australian Biodiversity Information Governance Group (AUSBIGG) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
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 |
|
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
-
A simple introduction to the concepts within ABIS
-
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 namespace - for this Standard |
|
|
ABIS Projects Model namespace |
|
|
BDR Dataset Namespace |
|
|
ABIS Data Release Model namespace |
|
|
ABIS Datatype Register namespace |
|
|
Extended Geometries Ontology |
|
|
|
Generic examples namespace - does not resolve |
|
GeoSPARQL Ontology namespace |
|
|
Web Ontology Language ontology namespace |
|
|
RDF Schema ontology namespace |
|
|
Sensor, Observation, Sample, and Actuator (SOSA) ontology namespace |
|
|
schema.org namespace |
|
|
Simple Knowledge Organization System (SKOS) ontology namespace |
|
|
TERN Ontology namespace |
|
|
Time Ontology in OWL namespace |
|
|
||
|
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.
- 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:
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:
-
Darwin Core - specialised properties for biodiversity modelling
-
Sensor, Observations, Sampling & Actuation (SOSA) ontology - sampling, observation & results modelling
-
GeoSPARQL - for spatial object modelling
-
Provenance Ontology (PROV) - for the lineage and attribution of data
-
schema.org - for general-purpose attributes like names, dates, simple metadata etc.
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":
-
Bibliographic Reference Ontology (BiRO)
-
A model for the description of reference lists and bibliographic references themselves
-
-
-
A model that relates models to other models
-
-
-
A model used to manage graphs of data with within a Knowledge Graph
-
ABIS also includes additional "component models" that extend the range of things ABIS can cover:
-
-
A basic model of projects that generate data
-
-
-
A model for data embargoes, withholding times and so on
-
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.
4.4. Related Standards
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.
-
-
This section. An informal overview of ABIS
-
-
-
Descriptions of important modelling choices made in ABIS and the models it inherits from
-
-
-
The normative description of the data models used within ABIS
-
-
-
Description of, and links to, the vocabularies needed for use with ABIS
-
-
-
A listing of known profiles of ABIS
-
-
-
How to validate data according to ABIS and links to the various validators
-
-
-
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
.
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 Dataset X contains a representation of Site Y and Site Y has the IRI of
http://linked.data.gov.au/dataset/ausplots-forest/site-nsfnnc0002
assigned to it by TERN, then that IRI MAY be used as the IRI for the site as it is resolvable online, linking to RDF data (and human-readable data) -
If Dataset X contains a representation of Sample Z and Sample Z has an International GeoSample Identifier (IGSN) or DOI IRI of
https://doi.org/10.58052/IECUR00N9
then that IRI MAY NOT be used as the IRI for the sample for, while it resolves online to a web page, it does not link to RDF data
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.
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.
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
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.
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 |
|
The spatial extents of the two objects are exactly the same |
disjoint |
|
The spatial extents of the two objects do not touch or overlap |
intersects |
|
The spatial extents of the two objects have at least one point in common |
touches |
|
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 |
|
The spatial extent of the first object is wholly contained by the spatial extent of the second object |
contains |
|
The spatial extent of the first object wholly contains the spatial extent of the second object (i.e. the inverse of within) |
overlaps |
|
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 |
|
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 |
---|---|---|---|---|
|
|
|
To indicate a time - to the second or part of a second - with a known timezone |
|
|
|
|
To indicate a time - to the second or part of a second - without a known timezone |
|
|
|
|
To indicate a date with time unknown or irrelevant |
|
|
|
|
To indicate a month in a particular year |
|
|
|
|
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 |
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.
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.
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.
Agents
related to a single dataset Entity
with different roles using the qualified attribution
predicate from PROVThe 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.
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.
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:
-
-
The main model that is the union of its Component Models
-
-
-
Parts of the Foreground Model that may be used independently
-
-
-
Models that Component Models profile
-
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
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.
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.
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.
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.
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.2. NSL Model
An overview of the main classes and predicates of the NSL Model is given in the figure below.
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:
Note
|
The NSL Model stated that a |
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.
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.
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.
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:
-
Darwin Core - specialised properties for biodiversity modelling
-
Sensor, Observations, Sampling & Actuation (SOSA) ontology - sampling, observation & results modelling
-
GeoSPARQL - for spatial object modelling
-
Provenance Ontology (PROV) - for the lineage and attribution of data
-
schema.org - for general-purpose attributes like names, dates, simple metadata etc.
-
Bibliographic Reference Ontology (BiRO) - for the description of reference lists and bibliographic references themselves
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 |
---|---|---|
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 |
|
Roles that |
Projects Model, range value for the predicate |
|
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 |
The BDR Profile of ABIS (this section) |
||
Machine-readable Profile Definition |
The machine-readable definition of this Profile, as per this text, but in RDF, according to The Profiles Vocabulary [PROF] |
||
Validator |
A SHACL file used to validate RDF data according to this Profile’s rules |
||
Data Expander |
A SHACL SHACL file used to expand RDF data according to this Specification’s rules |
||
Combined Validator & Expander |
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
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
Project
s are part of Program
s 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
ABIS Data Release Model |
|
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". |
|
2023-10-15 |
|
2023-12-28 |
|
2023-12-28 |
|
1.0 |
|
Version History |
2.0 - 2023 Dec - First release (v2.0 to match ABIS) |
the Department of Climate Change, Energy and the Environment (DCCEEW) |
|
Australian Biodiversity Information Governance Group (AUSBIGG) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
AusBIGG is supported by DCCEEW’s' Biodiversity Data Repository (BDR) Team. Contact the BDR Team on bdr@dcceew.gov.au |
|
Supporting Assets
-
RDF schema:
-
SHACL validation file:
Classes
Class Index
Classes defined here:
Classes defined elsewhere:
Project
Property | Value |
---|---|
|
|
This model |
|
Project |
|
An Activity that requires concerted effort following a Plan in pursuit of an objective |
|
Defined by BDR Team in 2023 in response to BDR usage needs |
|
Expected Properties |
|
: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
Property | Value |
---|---|
|
|
This model |
|
Project |
|
An Activity that requires concerted effort following a Plan in pursuit of an objective |
|
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 |
See the example for Project |
Attribution
Property | Value |
---|---|
|
|
Attribution |
|
The ascribing of an entity to an agent |
|
Use objects of this class to link Project or Program objects to Agent objects and the roles they played with respect to the Activity |
|
Expected Properties |
|
See the Example for Project: the range value for the |
Agent
Property | Value |
---|---|
|
|
Agent |
|
Something that bears some form of responsibility for an activity taking place |
|
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 |
|
Expected Properties |
None: use the Agent’s identifier only |
See the Example for Project |
Organization
Property | Value |
---|---|
|
|
This model |
|
Project |
|
An organization such as a school, NGO, corporation, club, etc. |
|
Defined by schema.org |
|
Expected Properties |
|
See the Example for Project |
Person
Property | Value |
---|---|
|
|
Agent |
|
Something that bears some form of responsibility for an activity taking place |
|
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 |
|
Expected Properties |
None: use the Agent’s identifier only |
See the Example for Project |
Concept
Property | Value |
---|---|
|
|
Concept |
|
An idea or notion; a unit of thought |
|
Direct use of this Class is not expected, instead where a |
|
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 |
---|---|
|
|
purpose |
|
The intent of the Activity |
|
Use this predicate to indicate a textual intent for a Project or a Program |
|
This model |
|
See the example for Project |
name
Property | Value |
---|---|
|
|
name |
|
The name of the item |
|
Use this predicate to indicate a textual name for something |
|
See the example for Project |
description
Property | Value |
---|---|
|
|
description |
|
A description of the item |
|
Use this predicate to indicate a textual description for something |
|
See the example for Project |
keywords
Property | Value |
---|---|
|
|
keywords |
|
Keywords or tags used to describe some item |
|
Use this predicate to indicate Concept instances from controlled vocabularies to categorise the object this predicate is applied to |
|
See the Example for Project |
has part
Property | Value |
---|---|
|
|
has part |
|
Indicates an item is part of this item |
|
Inverse of |
|
Use this predicate to indicate that a Program includes a See the example for Project |
|
See the example for Project |
is part of
Property | Value |
---|---|
|
|
is part of |
|
Indicates an item that this item, in some sense, is part of |
|
Inverse of |
|
Use this predicate to indicate that a Program includes a See the example for Project |
|
See the example for Project |
has time
Property | Value |
---|---|
|
|
has time |
|
Supports the association of a temporal entity (instant or interval) to any thing |
|
Use this predicate to indicate that a Program or a Project has a temporal region of concern |
|
See the example for Project |
hasGeometry
Property | Value |
---|---|
|
|
is part of |
|
A spatial representation for a given Feature |
|
Use this predicate to indicate that a Program or a Project has a spatial area of concern |
|
Range |
|
See the example for Project |
qualified attribution
Property | Value |
---|---|
|
|
qualified attribution |
|
The ascribing of an entity to an agent |
|
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 |
|
See the example for Project |
agent
Property | Value |
---|---|
|
|
agent |
|
References an Agent which influenced a resource |
|
Use this predicate to link an Project or a Program to an Agent, which must be an Organization or a Person |
|
See the example for Project |
had role
Property | Value |
---|---|
|
|
had role |
|
A role is the function of an entity or agent with respect to an activity |
|
Use this predicate to link an Project or a Program to a Concept |
|
See the example for Project |
generated
Property | Value |
---|---|
|
|
generated |
|
Generation is the completion of production of a new entity by an activity |
|
Use this predicate to link a Project or a Program to data that it produced, in the form of an |
|
See the example for Project |
Shapes
The following SHACL shapes are graph patterns mandated by this model.
Shapes Index
INCOMPLETE
IDN Roles
Property | Value |
---|---|
|
|
IDN Roles |
|
Roles for the predicate |
|
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
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
ABIS Data Release Model |
|
This model is for describing aspects of data release: to whom, under what circumstances and when data may be released. |
|
2023-10-15 |
|
2023-12-28 |
|
2023-12-28 |
|
1.0 |
|
Version History |
2.0 - 2023 Dec - First release (v2.0 to match ABIS) |
the Department of Climate Change, Energy and the Environment (DCCEEW) |
|
Australian Biodiversity Information Governance Group (AUSBIGG) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
AusBIGG is supported by DCCEEW’s' Biodiversity Data Repository (BDR) Team. Contact the BDR Team on bdr@dcceew.gov.au |
|
Supporting Assets
-
RDF schema:
-
SHACL validation file:
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 |
---|---|
|
|
embargoed until |
|
A date after which the is no longer embargoed |
|
This model |
|
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. |
|
# 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 |
---|---|
|
|
embargo period |
|
A temporal duration within which the object is embargoed |
|
This model |
|
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. |
|
# 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
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.
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.
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:
-
The datatype for the value indicated by the
tern:resultDateTime
predicate on the objectex:obs-01
is of an invalid datatype-
no datatype is given, so a string (
xsd:string
) is presumed but it should be anxsd:date
,xsd:dateTime
orxsd:dateTimeStamp
-
-
ex:obs-01
is missing ageo:hasGeometry
predicate -
ex:foi-01
is missing avoid:inDataset
predicate