NSL Model Overview
Figure 1. Models within the Profile

1. Metadata

IRI

https://linked.data.gov.au/def/bdr-pr

Name

BDR Profile of ABIS

Definition

This document is the normative specification of the Biodiversity Data Repository (BDR)'s profile of Australian Biodiversity Information Standard (ABIS).

Created Date

2025-03-29

Modified Date

2025-04-29

Issued Date

0000-00-00

Version

1.1

Version IRI

bdrpr:1.1

History Note

1.1 - 2025 Apr - Complete annex model docco & validators 1.0 - 2025 Mar - Initial version; extracted from the Profiles section of ABIS and some of its Appendixes

Creator

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

Owner

DCCEEW

Publisher

DCCEEW

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Contacts

The BDR Team on bdr@dcceew.gov.au

Issue tracking for this profile is managed online at https://github.com/dcceew-bdr/bdr-profile-of-abis/issues

Code Repository

https://github.com/dcceew-bdr/bdr-profile-of-abis

2. Abstract

This document is the normative specification of the Biodiversity Data Repository (BDR)'s profile of the Australian Biodiversity Information Standard (ABIS).

  • The BDR is a system implemented by the Department of Climate Change, Energy, the Environment and Water, in collaboration with Australian States and Territories.

  • ABIS is an Australian national standard for the representation and exchange of biodiversity information.

  • A profile is a "specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications" [W3C].

The purpose of this profile is to define requirements of data that is to be sent to the BDR, above and beyond those already imposed by ABIS. ABIS essentially defines the scientific information within data set to the BDR but does not define how to package that data, when it can be made available and so on. That is covered by this Profile.

3. Preamble

3.1. Parts of this Profile

  1. Specification

    • This document

    • Contains the normative expression of this profile. It sets out its relation to ABIS - as a standard that inherits from other standards - and a gives a list of , and description each of, its parts

  2. Vocabularies

    • ABIS, and the Profile, depend on many vocabularies

    • A listing of this Profile’s vocabulary dependencies is given and how and where they are used by this Profile’s models too

    • These are described in this specification’s Vocabularies Section below but are published and maintained elsewhere

  3. Validators

    • Data 'shape' files that can be used with validation tooling to check conformance of data to this Profile and the things that it profiles - ABIS and more fundamental data standards

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

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

bdrpr:

https://linked.data.gov.au/def/bdr-pr/

BDR Profile of ABIS' namespace

abis:

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

ABIS namespace

dr:

https://linked.data.gov.au/def/bdr-pr/dr/

BDR Data Release Model namespace

bdr:

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

BDR Dataset Namespace

proj:

https://linked.data.gov.au/def/bdr-proj/

BDR Projects Model namespace

dcat:

http://www.w3.org/ns/dcat#

Data Catalogue Vocabulary namespace

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

schema:

https://schema.org/

schema.org namespace

https://linked.data.gov.au/def/bdr-proj/:

https://linked.data.gov.au/def/bdr-pr/sm/

BDR Submission Manifest Model 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

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 Information Standard. The data standard mandated for the exchange of biodiversity information - species observations and related - between the Australian States, Territories and the Commonwealth.

This Profile is a profile of ABIS.

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 & the Commonwealth 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 tern:Result classes which only mean something in relation to the tern:Observation that generated them.

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 data are given in this document, RDF data serialised in the Turtle format is used. For example:

PREFIX ex: <https://example.com/dataset/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>

ex:x
    a tern:Dataset ;
    schema:name "Dataset X" ;
    schema:hasPart <https://example.com/dataset/sample/y> ;
.

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

The above example ABIS data provides a simple example of a dataset and a sample and a relationship between them, encoded in Turtle.

If prefixes - ex:, schema: and tern: in the example above - are not declared within the example, as they are here - lines starting PREFIX - then they will be found in the Namespaces table above.

4. Introduction

This document is the normative specification of the Biodiversity Data Repository (BDR)'s profile of the Australian Biodiversity Information Standard (ABIS).

The purpose of this profile is to define requirements of data that is to be sent to the BDR, above and beyond those already imposed by ABIS. ABIS essentially defines the scientific information within data set to the BDR but does not define how to package that data, when it can be made available and so on. That is covered by this Profile.

Note

ABIS may be used for data representation and data exchange with no reference to this this Profile if there is to be no involvement with the BDR. For example, it is perfectly acceptable for companies to exchange ABIS data amongst themselves.

However, this Profile is freely available for any use so anyone may use this Profile to represent and excahnge data if they wish.

The figure below, which is the same as the one at the start of this document, shows the envelope of this Profile with ABIS and the other models within it. See ABIS' Models Section for the details of the various models inside ABIS and the models that ABIS, in turn, profiles.

NSL Model Overview
Figure 3. Models within the Profile. Contained are ABIS - for scientific content - and Project, Data Release and Submission Manifest models for data management within the BDR.

4.1. Multiple Models

This Profile is centered on ABIS and provides a number of constraints on the use of ABIS, such as mandating certain metadata for Datasets. It also includes several models not found within ABIS that have been developed specifically for data management within the BDR. These models - the Project, Data Release and Submission Manifest models as shown in the figure above - are themselves mini-profiles of other, standard, models in that they mostly reuse classes and predicates from rather than inventing new ones.

The "Background Models" that these models inherit from and themselves profile are also the background models of ABIS - this Profile introduces no new ones. You can see the full list of ABIS', and therefore this Profile’s, background models at:

Since ABIS is well describes in the ABIS Specification, it will not be re-described in this Profile document. The following Models section described each of the other models within this Profile.

4.2. Governance

This Profile is governed by the BDR Team - the team that also operates the BDR.

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 and ABIS as a whole is governance 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.

Use of this Profile will always require use of ABIS and no changes will be introduced to this profile that conflict with ABIS.

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.3. 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. ABIS Constraints

    • Constraints that this profile places on the use of ABIS

  3. Models

    • The normative description of the models this profile uses in addition to ABIS

  4. Vocabularies

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

  5. Validation

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

Four additional models are defined in this Profile and detailed as Annexes in this document:

Extended examples are given in Annex D: Extended Examples.

5. Specification

The following subsections contain the rules of this Profile that go above and beyond those specified for ABIS generally. They form this Profile’s normative specification.

5.1. Required Identifiers

The BDR requires that certain classes of ABIS object use identifiers from particular systems. Some classes of identifier can be generated by a data submitter, based on a patter, others must be pre-allocated by the BDR Team.

Class Authority Pattern / Logic Description

tern:Dataset

Data Submitter

https://linked.data.gov.au/dataset/bdr/{UUID} where {UUID} is a UUIDv4

Most software libraries can generate this e.g. Python can call import uuid and then uuid.uuid4()

Alternate IRIs MAY be able to be used, for example for pre-existing datasets, if arranged with the BDR Team

tern:Site

Submitter or original Site creator

{Dataset-IRI}/ + supplier pattern or original IRI

If created by a supplier, the IRI must be based on the IRI of the Dataset that it is part of and must be unique within the Dataset.

Any system may be used to ensure uniqueness, e.g. UUIDs, systematic numbers etc.

tern:Sample

Submitter or original Sample creator

{Dataset-IRI}/ + supplier pattern or original IRI

As per Site

tern:Observation

Submitter or original Sample creator

{Dataset-IRI}/ + supplier pattern or original IRI

As per Site

prov:Agent, one of schema:Organisation or schema:Person, with a role in relation to a Dataset

BDR Team

Fixed, as registered

Agents with roles relating to a Dataset MUST be identified by IRIs as registered in the BDR Submitting Organisations vocabulary

prov:Agent, one of schema:Organisation or schema:Person, other relations

Submitter

Any

Agents other than those with roles relating to Datasets may be identified using any IRI or a Blank Node

schema:Datatype, as used with the schema:identifier predicate

BDR Team

Fixed, as registered

Datatypes indicated for literal values by the schema:identifier predicate MUST be identified by IRIs as registered in the BDR Datatypes vocabulary

5.2. 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 Datatype Notes

tern:Dataset

dcterms:title

1

xsd:string

tern:Dataset

dcterms:description

1

xsd:string

May use simple formatting such as linebreaks

tern:Dataset

dcterms:created

1

xsd:date

not xsd:dateTime or other date variant

tern:Dataset

dcterms:modified

1

xsd:date

not xsd:dateTime or other date variant

tern:Dataset

dcterms:creator

1+

IRI

the IRI of the Agent(s) must be listed in the BDR Submitting Organisations vocabulary

tern:Dataset

dcterms:publisher

1

IRI

the IRI of the Agent(s) must be listed in the BDR Submitting Organisations vocabulary

6. Models

This Profile is a profile of ABIS and also contains multiple other models used to represent information that ABIS does not address. The list of all models and their purposes is as follows.

6.1. Model Roles

Model Role

ABIS

to model scientific content - observations of biodiversity

Project

to link data to projects and programmes of work

Data Release

to record information about data withholding periods and other conditions for release

Submission Manifest

to describe packages of data submitted to the BDR for ingestion

6.2. Model Use Example

The following example data, which is not valida ccording to the BDR Profile of ABIS and is just for illustration purposes, includes elements from some of the models:

# An ABIS Dataset...
# containing a Biodiversity Occurrence Model Record
# and with attribution to a Project using the Project Model
# and with an embargo date from the Data Release Model
ex:dataset-01
    a tern:Dataset ;
    schema:hasPart ex:record-a ;
    prov:wasGeneratedBy ex:ProjectZ ;
    bdrpr:embargoedUntil "2025-06-30"^^xsd:date ;
.

# The Record is of a dwc:Occurrence as per standard ABIS modelling
ex:record-a
    schema:about ex:occurrence-x ;
.

# ABIS facts about the occurrence
ex:occurrence-x
    a dwc:Occurrence ;
    void:inDataset ex:dataset-01 ;
    geo:hasGeometry [
        a geo:Geometry ;
        geo:asWKT "POINT(143, -27)"^^geo:wktLiteral
    ] ;
.

The above information, if in a file called data.ttl, could be packaged and sent to the BDR in a submission described according to the Submission Manifest Model with this information:

[]
    a bdrsm:SubmissionManifest ;
    prof:hasResource [
        prof:hasArtifact "data.ttl" ;
        prof:hasRole https://linked.data.gov.au/def/bdr-proj/rr:SufficientForValidation ;
    ] ;
.

The example Submission Manifest data above tells us that all the data in this submission is within the file data.ttl and that it is "Sufficient for Validation", meaning that it can be validated as-is, without requiring any further information to be added to it, which may be the case in some submissions.

6.3. Models Overview

6.3.1. Project Model

Model location: Annex A

The Project Model defines a Project is defined as "An Activity that requires concerted effort following a Plan in pursuit of an objective". The expected use of Project is to represent real-world endeavours - often called projects or programmes - that generate biodiversity information that is submitted to the BDR. This use allows BDR data to be attributed to particular initiatives.

The joining point between this model and the rest of this Profile and ABIS is that datasets of ABIS data - instances of the tern:Dataset class - are produced by instances of the Project class as per the figure below.

How Projects in the Project Model relate to ABIS (TERN Ontology) Datasets
Figure 4. How Projects in the Project Model relate to ABIS (TERN Ontology) Datasets

6.3.2. Data Release Model

Model location: Annex B

This very small model provides predicates to introduce data release/withholding time periods and other information.

The joining point between this model and the res of this Profile and ABIS is that datasets of ABIS data - instances of the tern:Dataset class - can have Data Release Model predicates declared for them indicating release/withholding information for/from the BDR. This model could also be used to describe such information for/from other systems.

The following figure illustrates the basic use of this model.

How Data Release Model elements relate to ABIS (TERN Ontology) Datasets
Figure 5. How Data Release Model elements relate to ABIS (TERN Ontology) Datasets

6.3.3. Submission Manifest Model

Model location: Annex C

This model defines a submission manifest - a description of data submitted to the BDR in one or more data files, packaged in a compressed archive file format (zip).

The BDR Data Ingestion Pipeline - software that processes all submissions to the BDR - reads such manifests and processes the submission data according to properties within it and other metadata.

Submission Manifest information is used only to instruct the processing of data bound for the BDR (and potentially any other system wanting to also use this model) and no information in a Submission Manifest Model manifest file is stored within the BDR itself.

The example above in Model Use Example shows a simple example of a manifest file indicating a single data file - data.ttl. The manifest file, likely called submission.ttl, and the data file are required to be compressed and stored in a single ZIP file archive for submitting to the BDR.

7. Vocabularies

For data to conform to the BDR Profile of ABIS, many vocabularies must be used. Some of the vocabularies are required for use by ABIS - lists of measurement techniques, feature types etc. - others must be used for metadata values for ABIS objects. ABIS objects' metadata may require values such as "creator" for agent roles which the underlying TERN Ontology do not constrain, only requiring that some value be present and likewise, this profile may require particular values that ABIS does not constrain.

There are also elements of the models defined in this Profile that must be used with vocabularies, such as the Submission Manifest Model's hasRole predicate which must indicate a value from the Submission Manifest Resource Roles vocabulary.

7.1. Finding the vocabularies

All the vocabularies needed for use with this Profile, including ABIS and its background models, are listed within the BDR Portal's catalogue section:

8. Validation

Since this profile is a profile of ABIS, all data wanting to conform to this profile must conform to ABIS. Demonstration of conformance to ABIS means passing ABIS validator validation.

Then, to show conformance to this profile and not just ABIS, data must also pass this Profile’s validators.

8.1. ABIS Validation

ABIS requires data validation according to multiple validators:

These multiple validators are combined into a single ABIS Validator, for ease of use:

8.2. BDR Profile of ABIS Validation

This profile requires data validation according to multiple validators:

  • ABIS Validator

    • as above

  • The BDR Profile of ABIS Core Validator

  • Project Model Validator

  • Data Release Model Validator

  • Submission Manifest Validator

8.3. Combined Validators

The ABIS, BDR Profile of ABIS Core Validator, Project Model and Data Release Model validators are combined into a single validator for ease of use:

Note
The Submission Manifest Model validator is not included in the BDR Profile of ABIS Validator. This is because BDR Profile of ABIS data is stored within data files which cannot include manifest information and Submission Manifest Model data is stored in files that indicate data files but that do not contain data themselves.

8.4. Performing Validation

All data submitted to the BDR for ingestion will be validated using all the validators listed above within the BDR’s Data Ingestion Pipeline software. In addition, all the validators listed above can be selected for individual or combined use on the BDR Portal.

See ABIS' _Performing Validation section for information on other SHACL validation tool options.

Annex A: BDR Project Model

Projects Model Overview
Figure 6. Overview of the Project Model: A Project can be part of another Project or have as parts other Projects and can have basic metadata (name, related agents etc.), spatial, temporality and keywords associated with it

Projects can be part of larger projects are a specialised form of the Provenance Ontology's Activity class which is just a general temporal event. Activity instances, typically produce things and Project instances, in the context of the BDR, are expected to produce data held by the BDR.

Project instances can be part of larger Project instances which may be termed "Programmes".

Project instances can have simple metadata, such as names, descriptions, related agents and so on.

Also, as per PROV, some information about an Entity (data), produced by an Activity, can be inferred from the Activity, for example, the funder of a Project can be assumed to have funded (the production of) a Dataset it produced and the spatial area of the Project must surely contain the spatial area of the Dataset.

A.1 Metadata

IRI

https://linked.data.gov.au/def/bdr-pr/proj

Name

BDR Project 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-04-30

Issued Date

2025-04-30

Version

2.1

Version IRI

proj:2.0

Version History

2.1 - 2025 April - simplification to use schema.org Project

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

Creator

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

Owner

DCCEEW

Publisher

DCCEEW

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Contacts

The BDR Team on bdr@dcceew.gov.au

Issue tracking for this profile is managed online at https://github.com/dcceew-bdr/bdr-profile-of-abis/issues

Code Repository

https://github.com/dcceew-bdr/bdr-profile-of-abis

A.3 Classes

A.3.1 Class Index

Classes defined elsewhere:

A.3.2 Project

Projects Model Project Class
Figure 7. The Projects Model Project Class and its main relations
Property Value

IRI

schema:Project

Subclass of

Activity

Is Defined By

schema.org

Preferred Label

Project

Definition

An enterprise (potentially individual but typically collaborative), planned to achieve a particular aim

History Note

Taken directly from schema.org

Expected Properties

is part of, basic metadata predicates, spatial, temporality, keywords, generated, qualified attribution,

Example

PREFIX abis: <https://linked.data.gov.au/def/abis/>
PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX role: <http://def.isotc211.org/iso19115/-1/2018/CitationAndResponsiblePartyInformation/code/CI_RoleCode/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX time: <http://www.w3.org/2006/time#>

ex:project-m
    a schema:Project ;
    schema:isPartOf ex:program-n ;
    schema:name "Project M" ;
    schema:description "South Australian government Project M-23" ;
    abis:purpose "To determine extent of koala populations in NE SA" ;
    schema:keywords ex:koala ;
    schema:spatial
        [
            geo:asWKT "POLYGON ((138.010254 -26.007424, 140.976563 -25.99755, ..., 138.010254 -26.007424))" ;
        ] ;
    schema:temporality
        [
            time:hasBeginning [ time:inXSDDate "2020-12-01" ] ;
            time:hasEnd [ time:inXSDDate "2021-03-15" ] ;
        ] ;
    prov:qualifiedAttribution
        [
            prov:agent <https://linked.data.gov.au/org/dew> ;
            prov:hadRole role:principalInvestigator ;
        ] ;
    prov:generated ex:dataset-x ;
.

ex:program-n
    a schema:Project ;
    schema:hasPart ex:project-m ;
    schema:name "Programme N" ;
    # ... other properties
.

ex:dataset-x
    a tern:Dataset ;
    schema:name "Dataset X" ;
    # ... other properties
.

A.3.5 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 an prov:Attribution. schema.org's Person & Organization specialised forms of Agent are expected to be used.

Is Defined By

PROV

Expected Properties

None: use the Agent’s identifier only

Example

See the Example for Project

A.3.8 Dataset

Property Value

IRI

skos:Concept

Preferred Label

Dataset

Subclass of

Entity

Definition

A collection of data, published or curated by a single agent, and available for access or download in one or more representations.

Scope Note

Used for the outputs of a Project

Is Defined By

TERN Ontology

Expected Properties

None for this model: all properties are concerns of ABIS

Example

See the Example for Project

A.3.8 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 - all properties should be stored within the vocab the Concept comes from

Example

See the Example for Project

A.4 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 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

schema: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

schema: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

schema: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

schema: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 Project includes another Project

Is Defined By

SDO

Example

See the example for Project

is part of

Property Value

IRI

schema: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 Project is included within another Project

Is Defined By

SDO

Example

See the example for Project

spatial

Property Value

IRI

schema:spatial

Preferred Label

spatial

Definition

Spatial coverage

Scope Note

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

Is Defined By

schema.org

Range

Geometry

Example

See the example for Project

temporality

Property Value

IRI

schema:temporality

Preferred Label

temporality

Definition

Temporal coverage

Scope Note

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

Is Defined By

schema.org

Range

time:TemporalEntity

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 to a prov:Attribution which then links to an Agent with a prov:Role

Is Defined By

PROV

Range

prov:Attribution

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 prov:Attribution to an Agent

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 prov:Attribution to an prov:Role

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 to data that it produced, in the form of a tern:Dataset containing ABIS data

Is Defined By

PROV

Example

See the example for Project

A.5 Validator

The validator for this model is linked to in the C.2 Supporting Assets section above.

This validator should be used in conjunction with the main validator for the BDR profile of ABIS which is available in the Validation section above.

See the Validation section above also for information about how to perform validation.

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 schema:Project must be taken from the IDN Role Codes Vocabulary

Is Defined By

This model’s validator

Code

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

    ] ;
.

INCOMPLETE

Annex B: BDR Data Release Model

Overview of the Data Release Model
Figure 8. 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.

B.3 Classes

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

B.4 Predicates

C.4.1 Predicate Index

Predicates defined here:

C.4.2 embargoed until

Property Value

IRI

dr:embargoedUntil

Preferred Label

embargoed until

Definition

A date after which the is no longer embargoed

Is Defined By

This model

Domain

tern:Dataset

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

PREFIX : <http://example.com/thing/>
PREFIX dr: <https://linked.data.gov.au/def/bdr-pr/dr/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>


# Dataset X is embargoed until the 5th of May, 2024
:dataset-x
    a tern:Dataset ;
    schema:name "Dataset X" ;
    dr:embargoedUntil "2024-05-11"^^xsd:date ;
    # ... other dataset properties
.

# Dataset Y is embargoed until 2025
:dataset-y
    a tern:Dataset ;
    schema:name "Dataset Y" ;
    dr:embargoedUntil "2025-01-01"^^xsd:date ;
    # ... other dataset properties
.

C.4.3 embargo period

Property Value

IRI

dr:embargoPeriod

Preferred Label

embargo period

Definition

A temporal duration within which the object is embargoed

Is Defined By

This model

Domain

tern:Dataset

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

PREFIX : <http://example.com/thing/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX dr: <https://linked.data.gov.au/def/bdr-pr/dr/>
PREFIX schema: <https://schema.org/>
PREFIX tern: <https://w3id.org/tern/ontologies/tern/>
PREFIX time: <http://www.w3.org/2006/time#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

# 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
# able to be expressed in RDF

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

B.5 Validator

The validator for this model is linked to in the B.2 Supporting Assets section above.

This validator only validates manifest content, not the content of the data that the manifest lists - BDR/ABIS data.

Annex C: BDR Submission Manifest Model

Overview of the BDR Submission Manifest Modelverview of the Data Release Model
Figure 9. An overview of the BDR Submission Manifest Model

This model is for a manifest - a listing of contents - of data submissions to the [BDR]. The manifests are supplied as RDF files containing information according to this model within all data submissions to the BDR. The manifest information provides location, role and other information about all the data resources, allowing the BDR to process them correctly and efficiently.

C.3 Classes

C.3.1 Class Index

Classes defined here:

Classes defined elsewhere:

C.3.2 Submission Manifest

Property Value

IRI

sm:SubmissionManifest

Is Defined By

This model

Preferred Label

Submission Manifest

Definition

A listing of the content of a data submission to the BDR

History Note

Defined by BDR Team in 2025 to assist with the accurate and efficient processing of data submissions to the BDR

Expected Properties

has resource

Example

PREFIX prof: <http://www.w3.org/ns/dx/prof/>
PREFIX sm: <https://linked.data.gov.au/def/bdr-proj/sm/>
PREFIX smrr: <https://linked.data.gov.au/def/bdr-proj/smrr/>

[]
    a sm:SubmissionManifest ;
    prof:hasResource
        [
            a prof:ResourceDescriptor ;
            prof:hasArtifact "some-rdf-file.ttl" ;
            prof:hasRole smrr:SufficientForValidation ;
        ] ,
        [
            a prof:ResourceDescriptor ;
            prof:hasArtifact "images/some-image-file.jpg" ;
            prof:hasRole smrr:SupplementaryData ;
        ] ;
.

C.3.3 Resource Descriptor

Property Value

IRI

prof:ResourceDescriptor

Is Defined By

The Profiles Vocabulary

Preferred Label

Resource Descriptor

Definition

A resource that defines an aspect - a particular part or feature - of a Profile

History Note

Defined in PROF and reused directly in this model

Expected Properties

has artifact, has role

Scope Note

Treat the Submission Manifest as the Profile this class is related to

Example

See the example for Submission Manifest

C.4 Predicates

C.4.1 Predicate Index

Predicates defined elsewhere:

C.4.2 has resource

Property Value

IRI

prof:hasResource

Preferred Label

has resource

Definition

A resource which describes the nature of an artifact and the role it plays in relation to the Profile

History Note

Defined in PROF and reused directly in this model

Range

Resource Descriptor

Scope Note

Treat the Submission Manifest as the Profile this predicate requires

Example

See the example for Submission Manifest

C.4.3 has artifact

Property Value

IRI

prof:hasArtifact

Preferred Label

has artifact

Definition

The URL of a file with particulars such as its format and role indicated by the Resource Descriptor

History Note

Defined in PROF and reused directly in this model

Domain

Resource Descriptor

Scope Note

Can be used to indicate multiple files by file paths

Example

See the example for Submission Manifest

C.4.4 has role

Property Value

IRI

prof:hasRole

Preferred Label

has role

Definition

A description of a resource that defines an aspect - a particular part, feature or role - of a Profile

History Note

Defined in PROF and reused directly in this model

Domain

Resource Descriptor

Scope Note

Must be used to indicate a role from the Submission Manifest Model Resource Roles Vocabulary

Example

See the example for Submission Manifest

C.4.5 in scheme

Property Value

IRI

skos:inScheme

Preferred Label

in scheme

Definition

is in scheme

History Note

Defined in SKOS and reused directly in this model

Domain

Resource Descriptor

Scope Note

Must be used to indicate that a role used as the value for the has role predicate is within the Submission Manifest Model Resource Roles Vocabulary

Example

See the example for Submission Manifest

C.5 Validator

The validator for this model is linked to in the C.2 Supporting Assets section above.

This validator only validates manifest content, not the content of the data that the manifest lists - BDR/ABIS data.

C.6 Vocabularies

BDR Submission Manifest Resource Roles

This model depends on the Submission Manifest Model Resource Roles Vocabulary which is linked to in the C.2 Supporting Assets section above.

Concepts from this vocabulary MUST be used as values for the has role predicate.

C.7 Examples

C.7.1 MONITOR single

A single RDF file submission from the TERN MONITOR application.

This is a single RDF file - plant-tissue-lite-protocol-org-uuid-0fb52b7b-29f1-4797-920a-9c88f2180c5e-start-date-2024-12-11T06_53_43.879Z.ttl - sent from the MONITOR system to the BDR with no additional submission resources, such as image files.

PREFIX prof: <http://www.w3.org/ns/dx/prof/>
PREFIX schema: <https://schema.org/>
PREFIX sm: <https://linked.data.gov.au/def/bdr-proj/sm/>
PREFIX smrr: <https://linked.data.gov.au/def/bdr-proj/smrr/>

[]
    a sm:SubmissionManifest ;
    prof:hasResource
        [
            prof:hasArtifact "plant-tissue-lite-protocol-org-uuid-0fb52b7b-29f1-4797-920a-9c88f2180c5e-start-date-2024-12-11T06_53_43.879Z.ttl" ;
            prof:hasRole smrr:SufficientForValidation ;
            schema:description "A single file MONITOR submission" ;
            schema:name "Submission Data" ;
        ] ;
.

The manifest above points to the single data file and indicates that its Submission Manifest Resource Role is SufficientForValidation meaning this single data file can be validated as-is.

C.7.2 MONITOR multi

A multiple file submission from the TERN MONITOR application that includes both an RDF data file and also a number of image files.

PREFIX prof: <http://www.w3.org/ns/dx/prof/>
PREFIX schema: <https://schema.org/>
PREFIX sm: <https://linked.data.gov.au/def/bdr-proj/sm/>
PREFIX smrr: <https://linked.data.gov.au/def/bdr-proj/smrr/>

[]
    a sm:SubmissionManifest ;
    prof:hasResource
        [
            prof:hasArtifact "plant-tissue-lite-protocol-org-uuid-0fb52b7b-29f1-4797-920a-9c88f2180c5e-start-date-2024-12-11T06_53_43.879Z.ttl" ;
            prof:hasRole smrr:SufficientForValidation ;
            schema:description "A single file MONITOR submission" ;
            schema:name "Submission Data"
        ] ,
        [
            # every reference (path) to an image in a Submission's RDF data
            # must match a reference here. The DIP will replace local path
            # with paths to the BDR's image store locations
            prof:hasArtifact
                "images/image-001.jpg" ,
                "images/image-002.jpg" ,
                "images/image-003.jpg" ;
            prof:hasRole smrr:SupplementaryData ;
            schema:description "Images linked to from this submission's RDF data" ;
            schema:name "Submission Images"
        ] ;
.

The images are indicated as having a role of SupplementaryData meaning they will be handled in some way (stored) but not validated using ABIS validators. These image files must be linked to from within the submitted data.

C.7.3 Gaia archival

A submission from Gaia Resources with multiple RDF files and archival content.

PREFIX prof: <http://www.w3.org/ns/dx/prof/>
PREFIX schema: <https://schema.org/>
PREFIX sm: <https://linked.data.gov.au/def/bdr-proj/sm/>
PREFIX smrr: <https://linked.data.gov.au/def/bdr-proj/smrr/>

[]
    a smrr:SubmissionManifest ;
    prof:hasResource
        [
            prof:hasArtifact
                "outputs/dataset.ttl" ,
                "outputs/survey-metadata.ttl" ;
            prof:hasRole smrr:NecessaryForValidation ;
        ] ,
        [
            prof:hasArtifact "outputs/chunk_*.ttl" ;
            prof:hasRole smrr:IsolatedContent ;
        ] ,
        [
            # there must be a reference to this content in the RDF:
            # {DATASET-IRI} prov:wasDerivedFrom "inputs/"
            # which we will replace "input/" with an actual BDR archival
            # location, when created
            prof:hasArtifact "inputs/" ;
            prof:hasRole smrr:SubmissionSourceArchive ;
        ] ;
.

The survey- and dataset-level metadata stored in the files dataset.ttl and survey-metadata.ttl has the role NecessaryForValidation meaning it must be loaded for other resources to be validated but it is not itself directly validates. This is because it will likely be invalid: it’s metadata only and docesn’t include the actual core TERN Ontology observations data.

The second resource indicates a number of "chunk" files in a directory, each with the role IsolatedContent which means each can be validated in isolation from any other, but must have had the resource with role NecessaryForValidation loaded first - the required Dataset & Survey metadata.

The last resource is a set of files in a directory with the role SubmissionSourceArchive meaning it’s all to be archived - stored in the BDR’s provisioned archival storage unit - and not validated. These resources must be linked to from within the submitted data.

Annex D: Extended Examples

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

D.1. TERN Ontology

These examples use TERN Ontology elements only.

D.1.1. 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

D.1.2. 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:Dataset ;
    dcterms:description "A minimally valid tern:Dataset instance" ;
    dcterms:issued "2021-11-18"^^xsd:date ;
    dcterms:title "TERN Dataset 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> ;
.

D.1.3. 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:Dataset ;
    dcterms:description "A minimally valid tern:Dataset instance" ;
    dcterms:issued "2021-11-18"^^xsd:date ;
    dcterms:title "TERN Dataset 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

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

DCAT

World Wide Web Consortium, Data Catalog Vocabulary (DCAT) - Version 2, W3C Recommendation (04 February 2020). https://www.w3.org/TR/vocab-dcat/

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/

schema

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/

VocPub

Australian Government Linked Data Working Group, VocPub Profile, Profiles Vocabulary profile of SKOS (2020). https://w3id.org/profile/vocpub

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/