Queensland Spatial Information Supermodel

All the models in this Supermodel set are implemented using the Web Ontology Language OWL. OWL is a very widely used, standardised, formal modelling language. Unlike UML models, OWL models natively have machine-readable forms allowing data made according to them to be automatically validated and processed into databases.

The Supermodel’s constituent models are related to one another using The Profiles Vocabulary PROF which provides properties to indicate when and how one model reuses - "profiles" - another. PROF also links models to validators created to test data claiming conformance to them.

An Integrative Model is a main model that all the Component Models within a Supermodel context implement and extend for their specialised purposes. Supermodels always have one or mode of these.

In this Supermodel, the two Integrative Models are:

GeoSPARQL is used for the fundamental representation of spatial objects, for example in the Cadastre Model, a Parcel is a GeoSPARQL spatial Feature, as is an Addressable Object in the Address Model.

The Compound Naming Model is used to represent names for things that are made of many parts, including other names. The Address Model’s main class of Address is a specialised form of the Compound Naming Model’s Compound Name, as is the Geographical Naming Model's Geographical Name.

schema.org is used to provide common relationships between things such as has part - something being part of another thing.

Since all the Component Models reuse GeoSPARQL’s Feature, Compound Naming’s Compound Name and schema.org relations, the Component Models' specialised information is known to be patterned according to these models and thus certain assumptions about them can be made before even looking in to their specifics. For example, we can assume, correctly, that all spatial objects in all Component Models are linked to geometry representations of them via a has geometry relation (or specialised version thereof) and that all geometries are available in Well-Known Text Well-Known Text form, given that i a requirement for GeoSPARQL Geometry objects.

The following figure provides an overview of the main elements of the Integrative Models in this Supermodel.

Here is a list of terms and acronyms used in this document.

The structure of this document and the roles of each part are as follows:

This Supermodel is the total set models listed here.

The Backbone Model for this Queensland Spatial Information scenario overviewed in Figure 3. The elements of the Backbone Model are described next and the formal characterisation of the model in OWL is given in the machein-readable file backbone.ttl.

Figure 2 indicates two main conceptual domains (the yellow and blue) centered on Feature Labels (defined here) and geo:Feature s which are "Anything spatial (being or having a shape, position or an extent)" [GeoSPARQL]. Feature Labels are any form of identifying information assigned to a Feature [xxx].

The class hierharchy expressed in this Backbone Model (with sub class of arrows) indicates that:

The various Component Models (next) use these classes of object and imlplement many more specilised forms of them.

PIDs within this Supermodel are IRIs which means they are typically represented like an Internet web address:

{SCHEME}://{AUTHORITY}/{PATH}

e.g. - the PID for this Supermodel:

https://linked.data.gov.au/def/qsi-supermodel

where the SCHEME is the HTTPS protocol, the AUTHORITY is linked.data.gov.au and the PATH is def/qsi-supermodel.

IRIs in this form should be quoted in full wherever possible, i.e. within datasets, exchange data and documents.

This IRI for this Supermodel does indeed resolve as a web address, to this document:

The authority for all identifiers used in this Supermodel is linked.data.gov.au which is the Internet domain name allocated to the Australian Government Linked Data Working Group (AGLDWG) expressly for the purpose of creating IRI PIDs for Australian government.

PIDs using linked.data.gov.au must be registered with the AGLDWG.

Where an object cannot be identified with an IRI - perhaps the underlying technical system cannot store full web addresses - it may have an IRI substitute use which must consist of 2 data fields:

The Object Identifier part can be anything used to uniquely identify the object within the context of the system identified by the System Identifier, for example an auto-incrementing number, a structured number, a string or a UUID.

The System Identifier is the unique identifier for the system generating the Object Identifiers. It must be recorded in the table of Known Systems, below.

For each system identified in the Known Systems table below, a System PID Namespace is allocated. To assemble the IRI PID, the following logic is used:

IRI PID :== System PID Namespace / "dataset" / Object Identifier

For the Queensland Addressing & Location Information (QALI) system, the System Identifier is qali and the System PID Namespace is https://linked.data.gov.au/dataset/qld-addr, thus, for the Address with Object Identifier address/605bf8e7-315a-562b-af4c-16a870732daf, a class marker of "address" and a UUID, the complete IRI PID is:

https://linked.data.gov.au/dataset/qld-addr/address/605bf8e7-315a-562b-af4c-16a870732daf

Where a PID is represented in non IRI form and this must be stored in the RDF format, for example for exchange according to the Address Model, the Object Identifier must be represented as a literal with a custom datatype of the System Identifier and indicated with the schema:identifier if in an ontology or a dataset or skos:notation if in a vocabulary. For the address in the example above, this would look like the following:

The following kinds of PID are to be allocated to data objects in this Supermodel:

Models and vocabularies within this Supermodel, and the Supermodel itself, are assigned high-level definitional object PIDs as per the table below and allocate low-level definitional object PIDs within their namespaces.

The following are all the known systems creating identifiers for data within the scope of this Supermodel as well as known class markers used by them. The systems use high-level data object PIDs for their major datasets and low-level data object PIDs for each element of those datasets.

Unresolved Questions