1. Metadata
BDR Profile of ABIS |
|
This document is the normative specification of the Biodiversity Data Repository (BDR)'s profile of Australian Biodiversity Information Standard (ABIS). |
|
2025-03-29 |
|
2025-04-29 |
|
0000-00-00 |
|
1.1 |
|
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 |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
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 |
|
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
-
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
-
-
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
-
-
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 |
|
BDR Profile of ABIS' namespace |
|
|
ABIS namespace |
|
|
BDR Data Release Model namespace |
|
|
BDR Dataset Namespace |
|
|
BDR Projects Model namespace |
|
|
Data Catalogue Vocabulary namespace |
|
|
|
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 |
|
BDR Submission Manifest Model 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 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 thetern: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.
- 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 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.
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.
-
-
This section. An informal overview of ABIS
-
-
-
Constraints that this profile places on the use of ABIS
-
-
-
The normative description of the models this profile uses in addition to ABIS
-
-
-
Description of, and links to, the vocabularies needed for use with ABIS
-
-
-
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 |
---|---|---|---|
Data Submitter |
|
Most software libraries can generate this e.g. Python can call |
|
Submitter or original Site creator |
|
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. |
|
Submitter or original Sample creator |
|
As per Site |
|
Submitter or original Sample creator |
|
As per Site |
|
|
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 |
|
Submitter |
Any |
Agents other than those with roles relating to Datasets may be identified using any IRI or a Blank Node |
|
BDR Team |
Fixed, as registered |
Datatypes indicated for literal values by the |
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 |
---|---|---|---|---|
|
1 |
|
||
|
1 |
|
May use simple formatting such as linebreaks |
|
|
1 |
|
not |
|
|
1 |
|
not |
|
|
1+ |
IRI |
the IRI of the Agent(s) must be listed in the BDR Submitting Organisations vocabulary |
|
|
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 |
---|---|
to model scientific content - observations of biodiversity |
|
to link data to projects and programmes of work |
|
to record information about data withholding periods and other conditions for release |
|
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.
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.
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:
-
several background model validators
-
e.g. the GeoSPARQL Validator
-
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:
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
Project
s 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
BDR Project 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-04-30 |
|
2025-04-30 |
|
2.1 |
|
2.1 - 2025 April - simplification to use schema.org Project 2.0 - 2023 Dec - First release (v2.0 to match ABIS) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
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 |
|
A.2 Supporting Assets
-
RDF schema:
-
SHACL validation file:
A.3 Classes
A.3.1 Class Index
Classes defined elsewhere:
A.3.2 Project
Property | Value |
---|---|
|
|
Project |
|
An enterprise (potentially individual but typically collaborative), planned to achieve a particular aim |
|
Taken directly from schema.org |
|
Expected Properties |
is part of, basic metadata predicates, spatial, temporality, keywords, generated, qualified attribution, |
|
A.3.5 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 an |
|
Expected Properties |
None: use the Agent’s identifier only |
See the Example for Project |
A.3.8 Dataset
Property | Value |
---|---|
|
|
Dataset |
|
A collection of data, published or curated by a single agent, and available for access or download in one or more representations. |
|
Used for the outputs of a Project |
|
Expected Properties |
None for this model: all properties are concerns of ABIS |
See the Example for Project |
A.3.8 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 - all properties should be stored within the vocab the Concept comes from |
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 |
---|---|
|
|
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 Project includes another 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 Project is included within another Project |
|
See the example for Project |
spatial
Property | Value |
---|---|
|
|
spatial |
|
Spatial coverage |
|
Use this predicate to indicate that a Project has a spatial area of concern |
|
See the example for Project |
temporality
Property | Value |
---|---|
|
|
temporality |
|
Temporal coverage |
|
Use this predicate to indicate that a Project has a temporal region of concern |
|
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 to a |
|
See the example for Project |
agent
Property | Value |
---|---|
|
|
agent |
|
References an Agent which influenced a resource |
|
Use this predicate to link an |
|
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 |
|
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 to data that it produced, in the form of a |
|
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 |
---|---|
|
|
IDN Roles |
|
Roles for the predicate |
|
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
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.1 Metadata
BDR 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 |
|
2025-04-29 |
|
2023-12-28 |
|
1.1 |
|
2.0 - 2023 Dec - First release (v2.0 to match ABIS) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
Australian Biodiversity Information Governance Group (AUSBIGG) |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
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 |
|
B.2 Supporting Assets
-
RDF schema:
-
SHACL validation file:
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 |
---|---|
|
|
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. |
|
|
C.4.3 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. |
|
|
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
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.1 Metadata
BDR Submission Manifest Model |
|
This model is for a manifest - a listing of contents - of data submissions to the [BDR] |
|
2205-02-15 |
|
2025-04-29 |
|
2025-03-01 |
|
1.0 |
|
1.0 - 2025 Mar - First release |
|
Department of Climate Change, Energy and the Environment (DCCEEW) |
|
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 |
|
C.2 Supporting Assets
-
RDF schema:
-
SHACL validation file:
-
Submission Manifest Model Resource Roles vocabulary:
C.3 Classes
C.3.1 Class Index
Classes defined here:
Classes defined elsewhere:
C.3.2 Submission Manifest
Property | Value |
---|---|
|
|
This model |
|
Submission Manifest |
|
A listing of the content of a data submission to the BDR |
|
Defined by BDR Team in 2025 to assist with the accurate and efficient processing of data submissions to the BDR |
|
Expected Properties |
|
|
C.3.3 Resource Descriptor
Property | Value |
---|---|
|
|
Resource Descriptor |
|
A resource that defines an aspect - a particular part or feature - of a Profile |
|
Defined in PROF and reused directly in this model |
|
Expected Properties |
|
Treat the Submission Manifest as the Profile this class is related to |
|
See the example for Submission Manifest |
C.4 Predicates
C.4.1 Predicate Index
Predicates defined elsewhere:
C.4.2 has resource
Property | Value |
---|---|
|
|
has resource |
|
A resource which describes the nature of an artifact and the role it plays in relation to the Profile |
|
Defined in PROF and reused directly in this model |
|
Treat the Submission Manifest as the Profile this predicate requires |
|
See the example for Submission Manifest |
C.4.3 has artifact
Property | Value |
---|---|
|
|
has artifact |
|
The URL of a file with particulars such as its format and role indicated by the Resource Descriptor |
|
Defined in PROF and reused directly in this model |
|
Can be used to indicate multiple files by file paths |
|
See the example for Submission Manifest |
C.4.4 has role
Property | Value |
---|---|
|
|
has role |
|
A description of a resource that defines an aspect - a particular part, feature or role - of a Profile |
|
Defined in PROF and reused directly in this model |
|
Must be used to indicate a role from the Submission Manifest Model Resource Roles Vocabulary |
|
See the example for Submission Manifest |
C.4.5 in scheme
Property | Value |
---|---|
|
|
in scheme |
|
is in scheme |
|
Defined in SKOS and reused directly in this model |
|
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 |
|
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
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.
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.
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:
-
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
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/