A Semantic Web data model used for address information

Overview
Figure 1. An informal model overview diagram showing the major elements of this model

1. Metadata

IRI

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

Preferred Label

Address Model

Definition

A Semantic Web data model of address information that caters specifically for Australian & New Zealand’s address modelling needs

Created

2021-12-16

Modified

2024-06-26

Issued

2023-07-03 - not formally issued yet

Creator

Nicholas J. Car

Publisher

Queensland Spatial Information

Provenance

This model was originally developed between 2021 and 2023 for Queensland Spatial Information, a unit of the Queensland Department of Resources, to assist with their future address database design. It is informed by the ICSM’s Addressing 2035: Addressing Reform and Innovation for Australia and New Zealand, published in late 2021, which listed 'pain points' with current ANZ address models and considered future address modelling needs. This model tries to address the 10 main Requirements established by the Strategy. This model is also informed by both the relational database model used for the G-NAF, Australia’s Geocoded National Address File, and CSIRO work in 2018 to characterise the GNAF in Semantic Web form, the ontology for which is online at https://linked.data.gov.au/def/gnaf, as well as the ISO’s ISO19160-1 Addressing Part 1: Conceptual model. In 2023, several parts of this model covering general modelling issues, such as lifecycle representation, were extracted out into a series of mini-models to allow other models to reuse them without importing this model. As a result, the 2023 version fo this model appears to be greatly reduced in complexity and coverage but coverage is unchanged with those mini-models are also used.

Status

First stable version

Version

addr:1.0.1

Code Repository

https://github.com/Spatial-Information-QLD/address-model

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Copyright

© The State of Queensland (Department of Resources) 2020-2023

Machine-readable form (RDF)

https://linked.data.gov.au/def/addr.ttl

2. Preamble

2.1. Abstract

Note
 This Model is under test by Queensland Government and is a candidate model for Australian & New Zealand address information. It is currently an unofficial model that is not yet published as a standard.

A Semantic Web data model of address information that caters specifically for Australian & New Zealand’s address modelling needs.

This model was originally developed between 2021 and 2023 for Queensland Spatial Information, a unit of the Queensland Department of Resources, to assist with their future address database design. It is informed by the ICSM’s Addressing 2035: Addressing Reform and Innovation for Australia and New Zealand, published in late 2021, which listed 'pain points' with current ANZ address models and considered future address modelling needs. This model tries to address the 10 main Requirements established by the Strategy. This model is also informed by both the relational database model used for the G-NAF, Australia’s Geocoded National Address File, and CSIRO work in 2018 to characterise the GNAF in Semantic Web form, the ontology for which is online at https://linked.data.gov.au/def/gnaf, as well as the ISO’s ISO19160-1 Addressing Part 1: Conceptual model. In 2023, several parts of this model covering general modelling issues, such as lifecycle representation, were extracted out into a series of mini-models to allow other models to reuse them without importing this model. As a result, the 2023 version fo this model appears to be greatly reduced in complexity and coverage but coverage is unchanged with those mini-models are also used.

2.2. Namespaces

This model is built on a small set of well-regarded Semantic Web models which use a variety of namespaces. Additionally, this model is expected to be used with a series of mini-models which were created alongside it and they also used namespaces. Prefixes for these namespaces, used throughout this document, are listed below.

Prefix Namespace Description

addr

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

This model

als

https://linked.data.gov.au/def/address-lifecycle-stage-type/

Address Lifecycle Stage Types vocabulary

apt

https://linked.data.gov.au/def/address-part-type/

Address Part Types vocabulary

asgsed3

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

Australian Statistical Geographies Standard Dataset, Release 3

cn

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

Compound Naming Model

ex

http://example.com/

Generic examples

geo

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

OGC GeoSPARQL

gt

http://www.opengis.net/ont/geocode-types/

Geocode types vocabulary

ls

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

Lifecycle Model

owl

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

Web Ontology Language ontology

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

The RDF Concepts Vocabulary

rdfs

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

RDF Schema ontology

sosa

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

Sensor, Observation, Sample, and Actuator ontology

sdo

https://schema.org

schema.org model

skos

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

Simple Knowledge Organization System (SKOS) ontology

time

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

Time Ontology in OWL

void

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

Vocabulary of Interlinked Data (VoID) ontology

xsd

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

XML Schema Definitions ontology

2.3. Conformance

This model’s specification conforms to the OntPub Profile which is a standard for ontology publication that mandates certain structural and metadata properties for the model as a whole and model elements.

2.3.1. Figures

Figures used in this document use the following key:

Key
Figure 2. Key of elements used in this Model’s figures

2.3.2. Example Data

Example data used in this document, for instance in model element "Example" values, are RDF data presented in the TTL syntax.

3. Introduction

This model considers addresses - 'street addresses' - to be a form of compound name for a geospatial feature. For example, the Australian address:

72 Yundah Street
Shorncliffe QLD
4017 Australia

is a form of name for the cadastral parcel that defines a particular property’s extend - a 'lot'.

Addresses modelled according to this model do more than just name things though: they are linked to geocodes - spatial points - allowing for map-based locating and route planning, sometimes other addresses for the same spatial object, sometimes parent/child addresses for dwelling compounds and management information such as lifecycle stages.

Overall, this model represents addresses, certain properties for them, including address parts, geocodes and the objects to which addresses are assigned in a conceptual manner similar to the international addressing standard, ISO19160-1. However, this model is expressed in Semantic Web[1] form, rather than ISO19160-1’s UML and XML, and many aspects of the conceptual range that ISO19160 covers this model does not directly cover but instead delegates to other models which it imports, such as the representation of address and address part lifecycle information. This is done so that common things that this model does are available for use elsewhere via a series of mini-models that others may use without importing this whole model.

Additionally, this model relies on several specialised sub-models to handle specific types of address parts, such as streets and geographical object naming. By doing this, those things many be modelled independently of addressing and streets and geographic object names datasets can be used with address data very easily.

This model makes no attempt to model the things to which addresses are assigned. In the example above, the address "72 Yundah St…​." is mentioned as being a form of name for, or assigned to, a cadastral parcel or a 'lot'. This model doesn’t know what those things are and leaves their modelling to other systems. This means that using this model alone, you cannot know what an address is for unless you implement an address part to describe the type of object the address is assigned to. This decision has been made since there could be great complexity in spatial object / infrastructure modelling that isn’t really core to addressing, so that’s best left to other, likely sophisticated, models.

3.1. Sources of Requirements

In 2021, the Australia and New Zealand Intergovernmental Committee on Surveying and Mapping established an Addressing 2035 Strategy that aimed to "provide leadership, coordination and standards for assembling, delivering and maintaining address datasets". The Strategy listed "Strategic Pillars", such as "Jurisdictional flexibility" - things for Strategy implementers to aim for - "Guiding Principles", "Overarching Pain Points" and other system/model/situation requirements. While the Strategy did not present an address model, it had an addendum that listed 10 requirements for a future address data model: Addendum to the Strategy. These 10 requirements are a major source of this Address Models requirements.

These ICSM requirements include both specific requirements, for example to cater for "Multi-lingual and alternate name addressing", and also requirements to align with other address-related initiative which might be a source of multiple individual requirements, for example "Model interoperability" which, in its detailed description, indicates a requirement for an address model to align with a baseline set of spatial data standards that ICSM might create.

Annex A: Requirements lists the ICSM Addressing 2035 Strategy Addendum’s 10 requirements and indicates how this model implements solutions for them.

3.2. Major Modelling Principles

Major modelling principles present in this model are:

  1. Model Reuse

  2. External Vocabularies

  3. Feature / Feature Naming differentiation

  4. Feature / Geometry differentiation

  5. Geocodes

  6. Address Parts

  7. Street & Geographical Names

  8. Address part typing

  9. Address part templating

  10. Water-based Addressing

  11. Related Addresses

  12. Status Authority & Lifecycles

These principles are explained in the following subsections and the first two reference the following figure.

3.2.1. Model Reuse

The Semantic Web contains many widely-used models and model reuse is a greatly favoured practice for Semantic Web modelling for, if models are reused, data created according to them is instantly compatible with other data. Additionally, many Semantic Web models have deep thought behind them that no single modelling initiative could hope to match easily.

The well-known Semantic Web models that this model inherits from are:

  • Web Ontology Language OWL: a widely-used set theory-based general-purpose model that uses the RDF data structure

  • schema.org SDO: a general-purpose model of classes and properties used by many website publishers to present structured data to search engines

  • GeoSPARQL GEO: the Open Geospatial Consortium’s[2] ontology for basic features and geometries modelling

  • Simple Knowledge Organization System SKOS: a simple OWL model for organizing taxonomies of concepts

Some aspects of addressing that were originally modelled within this model at its first release in 2021 have been discovered to be generic in nature but yet not already modelled in a Semantic Web ontology appropriate for use here. For those aspects of addressing, a series of mini-models have been created to allow the generic parts to be published independently of addressing, allowing for independent and hopefully greater reuse. The main mini-models factored out of this model are:

  • Compound Naming Model CNM: modelling of names objects, parts of names, and the things names are assigned to

  • Lifecycles Model LM: modelling of lifecycles for anything - whole addresses, parts of addresses etc.

3.2.2. External Vocabularies

Some elements of addresses must be subclassified by, or in some other way associated with, terms from vocabularies. The most prominent example is the expression of the type of part of an address: is it a street number, a flat type or a postcode?

Where such vocabularies are used, they are not directly published within this model but externally and this model is expected to be used with them. In this way, vocabularies may be extended without extending this model and different users may implement their own vocabularies to suite their business needs, for example, perhaps not all model users allow all address part types Queensland does, such as water feature number so, they should use this model with a vocabulary that excludes that term.

See the Supporting Vocabularies section for mode information.

3.2.3. Feature / Feature Naming differentiation

This model details the elements of an address but not details of the spatial objects that addresses are assigned to. The general conceptual split of address/spatial object follows the Address/AddressableObject split in ISO19160-1 ISO19160-1. Addresses are seen as a form of complex, multi-part, name for a spatial Feature.

This allows for the representation, and ultimately the management, of names - text, numbers, identifiers, references - separately to the management of spatial objects.

This Feature / Feature Naming separation applies to Geographical objects, Streets and Administrative Areas as well as Addresses and the first two of those three objects have models similar to this one for their names, GN & ROADS.

Some elements of this Feature / Feature Naming pattern, used by this and the two models mentioned above, are captured in the general-purpose Compound Naming Model CNM which they all inherit from.

3.2.4. Feature / Geometry differentiation

(Geo)spatial objects referenced by this model are not geometries but conceptual spatial objects that may have as an expression of their spatial projection one or more geometries. This conceptual object / spatial expression differentiation, which we refer to as a Feature / Geometry split, is based on fundamental spatial modelling in standards such as ISO19101-1 and their expression in the Semantic Web spatial standard GEO.

This Feature / Geometry split allows individual spatial objects to have multiple Geometries: different resolutions, in different coordinate systems and even sets of Geometries that have different roles or that show variation over time.

While this model doesn’t model spatial aspects of the object to which addresses are assigned - see the section above - this Feature / Geometry split and expressions of geometry are modelled for geocodes - see next section.

3.2.5. Geocodes

Geocodes are spatial objects - Features - with point geometries that addresses may be associated with so that they can be used by mapping applications to locate the address, or part of an addressable object, on a map or on the earth.

Geocodes may be only indirectly related to an Addressable Object: while they may be calculated from them, for example they could be the centroid of a lot, they may also not be, for example they could be a GPS-marked point indicating a property entrance point that is on or close to the Addressable Object but has been determined independently of its details.

For this reason, Geocodes are related to Addresses only in this model, not Addressable Objects, and any Geocode/Addressable Object relations are out-of-scope here.

3.2.6. Address Parts

Addresses are complex things: they are all made of multiple parts with different roles, types ordering and so on. To handle this, this model has a generic notion of a part which may be a simple thing, e.g. a postcode or a street number, but it may also be a complex thing, e.g. a street name that includes a "given" name for the street as well as some type indication.

This model inherits from the Compound Naming Model CNM which allows for Compound Names, such as Addresses, to link to parts which are also Compound Names which then link to other Compound Names. In this way, Addresses may be "built up" from compound names for a series of parts, such as street names, locality names and so on.

3.2.7. Street & Geographical Names

This model can be used to model all the parts of a street names - the 'given' part e.g. "Smith", a type indicator such as "Street" and perhaps a suffix, such as "South" - or it can be used to just indicate that a particular street is a part of an address and the name for that street is to be found in an independent object.

This second form - delegation of name - is allowed to facilitate point-of-truth datasets which both provide names for streets in isolation and are also used by address datasets.

Similarly, names for geographical objects, such as mountains, lakes, certain kinds of locality etc. may also be held independently of addressing data and just referred to as a complex object part of an address.

A model of streets - both naming and some physical presentation of them - has been created in parallel to this model, as has a model of Geographical Names which is a replacement for the various Placenames models found in ANZ, such as the FSDF Placenames Ontology. These models can be used independently as well as within this model. Their persistent web addresses are:

3.2.8. Address part typing

There are various given name parts of addresses which have previously been shoved into inappropriate data fields legacy address models and systems. For example, some models have contained building but not property names, so both types have been combined into the field for the former.

In this model, all address parts are just parts with a specialised type indicated with a reference to a concept within a vocabulary such as the Address Parts vocabulary (see Supporting Vocabularies). Implementations MUST allow for this type of "soft typing" (where a data object’s type is selectable from an external list) so that no field limitations such as the above occur.

Implementers can limit the part type vocabulary of course and will have to handel all the types they allow in the vocabulary, but implementers should not "make do" with inappropriate field (part type) reuse.

3.2.9. Address part templating

This model is a conceptual model of addressing information and implementations of it will need to make or use logical and physical models. 'conceptual', 'logical', and 'physical' are variants of data models that show different levels of detail/abstraction for different purposes[3].

None of the model types listed above provide logic for things like data presentation, so they will not be able to show you how to "print out" an address. So if I have an address' information represented according to this model and implemented in a graph, relational or other database system, I will still need business logic implemented in application code to realise the "print out".

This model expects implementers to use some form of templating to create address "print outs" and other forms of presentation.

While not a core part of this model, templating suggestions are presented in Annex C: Templating.

3.2.10. Water-based Addressing

The ability to cater for addresses reachable by watercraft was a requirement of Queensland’s project that generated this model. Water-based addressing is standardised in the Australian/New Zealand standard AS4189:2011 and it requires that water-based addressing use the name of the water feature as well as a water address number, the logic for the assignment of which is feature-specific, i.e. numbers for islands and for watercourses are determined differently.

This model indicates the use of a typed reference from an Address to a Water Feature object, just as Addresses reference Street or Locality objects, and then the Water Feature itself supplies the format of its name, including typing, e.g. Lord Howe Island or Slacks Creek any abbreviations or other name variants, e.g. Wop pa as an indigenous name variant of Great Keppel Island.

This model does not supply the logic for water number generation, just as it does not supply the logic for street number assignment, however it does provide address part types for water-based addressing, see the Address Part Types in the Supporting Vocabularies section.

This model does not provide templating or application logic to show how a water-based address should order water address parts or perhaps use water addressing parts and not street addressing parts: templating logic is exemplified in the templating annex Annex C: Templating and appropriate part usage logic is left to implementers.

3.2.11. Related Addresses

Many previous address models contain provisions for the modelling of related addresses. These may take the form of multiple addresses that are aliases for a single Addressable Object or perhaps "parent" and "child" addresses for a property with multiple sub-addresses and an overarching address, such as a unit complex.

This model does not implement any such logic for several reasons:

  1. Representing relations characterised outside of addressing data within addressing data fails to use point-of-truth information

    1. As per the introductory sentence above, logic for "parent" and "child" addressing or aliases is held in topological relationships or object identity, not addressing data

  2. Addressing information is almost always managed alongside information about the objects addressed

    1. This follows from the previous point: if object relations that an be used to infer address relations are available to address database implementers, they should be used directly, not re-implemented

  3. Previous Address models provide other properties for addresses that impact on address relations

    1. for example, two related addresses might only be fully understood when the authority of the addresses is also known

    2. this means properties are not independent and this is a data modelling anti-pattern as it introduced maintenance issues

Expected use of this model to cater for related addresses requires the combined use of this model with any other models, as per the section Model Reuse above, that contain the logic for relating addresses. Two examples of how related addresses could be represented by this model and the use of general topological rules, such as those provided by GeoSPARQL GEO are given next.

Emulating address aliases

Other address models state something such as:

AddressX isAliasOf AddressY

Or, the inverse:

AddrezzY hasAlias AddressX

This indicates that AddressX and AddressY are for the same Addressable Object. Other models may also indicate that, of the two addresses, one is preferred or in some way more authoritative, perhaps like this:

AddressX isPrimary True
AddressY isPrimary False

Taken together we have:

AddressX
    hasAlias AddressY
    isPrimary True

AddressXY
    hasAlias AddressX
    isPrimary False

If aliasing logic is that Addresses are aliases when they are both assigned to the same Addressable Object, then we can determine whether Addresses have aliases by just inspecting the identify of the thing they are addresses for. This would be implemented like this:

AddressX
    isAddressFor ObjectM

AddressY
    isAddressFor ObjectM

Since most address models require the identity of the thing an address is for - perhaps an Addressable Object, an address "Site" or similar, then this requires no additional information to see that an alias exists.

To cater for primary/secondary-style modelling, we look to the status of the addresses independently of their aliasing:

AddressX
    hasStatus Official

AddressY
    hasStatus Unofficial

As for addressable object identification, most address models have a mechanism for indicating status/officialness. This model does it by relating an Address to a Lifecycle Stage with a type, such as Official, and, if that Lifecycle Stage is current, then the address has that status. Informal modelling according to this model to emulate AddressX being a 'primary' and AddressY being a 'secondary' for the same object, with AddressY previously having been the 'primary' could be:

AddressX
    isAddressFor ObjectM
    hasLifecycleStage
        type Official
        status Current
    hasLifecycleStage
        type Unofficial
        status Expired

AddressY
    isAddressFor ObjectM
    hasLifecycleStage
        type Unofficial
        status Current
    hasLifecycleStage
        type Official
        status Expired
Emulating parent/child address relations

The most common logic for parent/child (or primary/secondary, whole/part or some other pair of mereological[4] terms) relations is that a parent address is for a large property such as a unit complex and that the child addresses are for the parts within the parent, such as units in the complex.

Such logic, at least for unit complexes is necessarily spatial: all the child units are spatially within the parent.

Since this model already relies on spatial representation and topological relations inherited from the GeoSPARQL GEO model, the emulation of parent/child addressing just uses GeosPARQL relationships for the Addressable Objects like this:

If AddressP is the parent of AddressK, AddressL & AddredssM, then we would expect to see modelling like this:

AddressP
    isAddressFor ObjectP

AddressK
    isAddressFor ObjectK

AddressL
    isAddressFor ObjectL

AddressM
    isAddressFor ObjectM

ObjectK isWithin ObjectP
ObjectL isWithin ObjectP
ObjectM isWithin ObjectP

Other standard topological relations could be used so that the inverse to within, contains, could be stated:

AddressP
    isAddressFor ObjectP

AddressK
    isAddressFor ObjectK

AddressL
    isAddressFor ObjectL

AddressM
    isAddressFor ObjectM

ObjectP
    contains
        ObjectK
        ObjectL
        ObjectM

Not that it’s common in existing address models, but sibling addresses could be emulated in this way by using a touches relation between Addressable Objects.

3.2.12. Status Authority & Lifecycles

Other address models provide for notions of authority - whether addresses are ratified by some authoritative body or not - separately to notions of lifecycle - where, in stages of development an address is. This model does not and instead indicates status and authority all-in-one with relations from an Address to one or more Lifecycle Stages which can indicate both a particular Stage or status and a temporal range, as per the Lifecycle Model LM.

An informal address may be indicated like this:

AddressX
    hasLifecycleStage
        status Informal

If an address is proposed in the 1st of January, 2023, and it is not yet accepted/ratified, thus it is still informal, it could be modelled like this:

AddressX
    hasLifecycleStage
        startDate 2023-01-01
        status Proposed

If that address became formal, status 'Ratified', on the 1st of June, 2023, then you might have:

AddressX
    hasLifecycleStage
        startDate 2023-06-01
        status Ratified
    hasLifecycleStage
        startDate 2023-01-01
        endDate 2023-06-01
        status Proposed

See the Annex D: Extended Examples for formal examples of this modelling.

Implementers are free to create their own Lifecycle Stage types - statuses - using vocabularies.

3.3. Model resources

This document is this model’s "Specification" which is its authoritative, human-readable, definition document. This model also contains other resources with other roles:

Resource Role Notes

Ontology

Schema

The technical, machine-readable, version of this model

Supporting Vocabularies

Vocabulary

The codelist vocabularies developed for this model and links to others defined elsewhere but expected to be used by this model

Annex A: Requirements

Guidance

The Requirements formally addressed by this model

Annex B: Validation & Validator

Validation

The machine-readable validator file used to validate data claiming conformance to this model

Annex C: Templating

Guidance

Suggestions and examples of templating for address presentation

Annex D: Extended Examples & Extended example data files

Example

Examples of data conforming, and some not conforming, to this model

4. Model

This model is composed of Web Ontology Language (OWL) OWL Classes and Properties. While some of the properties are restricted in their use to various classes, the Classes and Properties are actually defined individually and both are "first class model citizens", with global identity, that can be used in isolation as well as together. This is in contrast to Unified Modelling Language (UML) Class Diagrams which treat most Properties as element of particular Classes.

This model defines only three Classes and no Properties but reuses many Classes and Properties from other models. Where it does, basic details of, a reference to that Class or Properties' definition via rdfs:isDefinedBy, and a scope note about using it in this model are given.

Overview
Figure 3. Overview of this model showing major elements
upper classes
Figure 4. Mapping of the main model classes to common Semantic Web classes

4.1. Classes

4.1.1. Classes defined by this model

4.1.2. Address

Property Value

IRI

addr:Address

Preferred Label

Address

Definition

The Address class represents structured information that allows unambiguous identified of an object for the purposes of identification and location

Is Defined By

This model

Subclass Of

Compound Name

Provenance

Derived from ISO19160-1's Address class

Expected Properties

is name for, hasPart, hasGeocode, has lifecycle stage,

Example

 
PREFIX addr: <https://linked.data.gov.au/def/addr/>
PREFIX apt: <http://linked.data.gov.au/def/address-part-types/>
PREFIX cn: <https://linked.data.gov.au/def/cn/>
PREFIX ex: <http://example.com/>
PREFIX ex-geom: <http://example.com/geometry/>
PREFIX ex-parcel: <http://example.com/parcel/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX ls: <https://linked.data.gov.au/def/lifecycle/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sdo: <https://schema.org/>

<http://example.com/oxford>
    a addr:Address ;
    sdo:hasPart [
        sdo:additionalType apt:numberFirst ;
        rdf:value 20
    ] ,
    [
        sdo:additionalType apt:street ;
        rdf:value <https://linked.data.gov.au/dataset/qldaddr/streetLocality/QLD140492> ; # "Oxford Place"
    ] ,
    [
        sdo:additionalType apt:locality ;
        rdf:value <https://linked.data.gov.au/dataset/qldaddr/locality/loc38f189794e03> ;  # "Shorncliffe"
    ] ,
    [
        sdo:additionalType apt:administrativeArea ;
        rdf:value <https://linked.data.gov.au/dataset/asgsed3/STE/3> ; # "Queensland"
    ] ,
    [
        sdo:additionalType apt:postcode ;
        rdf:value 4017
    ] ;
    addr:hasGeocode [
        geo:hasGeometry [
            sdo:additionalType <https://linked.data.gov.au/def/geocode-types/property-centroid> ;
            geo:hasGeometry ex-geom:x ;
        ] ;
    ] ;
    cn:isNameFor ex-parcel:161162441 ;
    ls:hasLifecycleStage [
        sdo:additionalType ex:Unofficial ;
    ] ;
.

4.1.3. Addressable Object

Property Value

IRI

addr:AddressableObject

Preferred Label

Addressable Object

Definition

An object that is unambiguously identified by an address.

Examples of types of AddressableObjects are a building, a dwelling or a land parcel

Is Defined By

This model

Subclass Of

Feature

Provenance

Derived from ISO19160-1's AddressableObject class and its associated codelist of subtypes

Scope note

Judgement as to what makes for a permissible AddressableObject rests with the implementer. This model’s technical requirements are only that the object is a legal geo:Feature object, thus implementers may make Addressable Objects of almost anything.

Expected Properties

hasGeometry

Example

 
PREFIX addr: <https://linked.data.gov.au/def/addr/>
PREFIX cn: <https://linked.data.gov.au/def/cn/>
PREFIX ex: <http://example.com/>
PREFIX sdo: <https://schema.org/>

ex:oxford
    a addr:Address ;
    cn:isNameFor ex:cadastral-parcel-x ;
.

ex:cadastral-parcel-x
    a ex:Parcel ;
.

# inferred
ex:cadastral-parcel-x
    sdo:name ex:oxford ;
.

4.1.4. Geocode

Property Value

IRI

addr:Geocode

Preferred Label

Geocode

Definition

A point Feature used to position other Features and to which additional typing or roles may be assigned

Is Defined By

This model

Subclass Of

Feature

Provenance

Derived from the G-NAF’s expression of Address position

Scope note

Indicating a Geocode for an Address with the property hasGeocode is a direct method of locating the Address. Addresses either may also be located by reference to an Addressable Object which may a Geometry. This model does not indicate any Geocode / Addressable Object geometry relations although they may exist

Expected Properties

additionalType - use to indicate a Geocode Type, as per the Geocode Type

geo:hasGeometry - to indicate the position of the Geocode. A GeoSPARQL Geometry.

Example

 
# An Address with a Geocode and a role
ex:addr-1
  a addr:Address ;
    addr:hasGeocode [
      a addr:Geocode ;
      dcterms:type geocodeType:DF ;  # Driveway Frontage
      geo:hasGeometry "POINT (152.01 -35.03)"^^geo:wktLiteral ;
    ] ;
    addre:hasRole addr:buildingAccessPoint ;
    ...

4.1.5. Existing classes reused by this model

4.1.6. Compound Name

Property Value

IRI

cn:CompoundName

Preferred Label

Compound Name

Definition

A Compound Name is a literal value, or objects that can be interpreted as literal values, that describe or name a Feature

Is Defined By

CNM

Scope Note

The basis for the Address class. This class is also used for instances of Address Part parts

4.1.7. Lifecycle Stage

Property Value

IRI

lm:LifecycleStage

Preferred Label

Compound Name

Definition

A Compound Name is a literal value, or objects that can be interpreted as literal values, that describe or name a Feature

Is Defined By

LM

Scope Note

Used to indicate the lifecycle stage of any Address model part. Different stage types may be necessary for different class instances such as Road Name and Road Object and may be sourced from different vocabularies

4.1.8. Feature

Property Value

IRI

geo:Feature

Preferred Label

Feature

Definition

A discrete spatial phenomenon in a universe of discourse

Is Defined By

GEO

Scope Note

Used as the basis for the Addressable Object class

4.1.9. Geometry

Property Value

IRI

geo:Geometry

Preferred Label

Geometry

Definition

A coherent set of direct positions in space. The positions are held within a Spatial Reference System (SRS).

Is Defined By

GEO

Scope Note

Used to give spatial representation information for a Road Object

4.1.10. Concept

Property Value

IRI

skos:Concept

Preferred Label

Concept

Definition

An idea or notion; a unit of thought

Is Defined By

SKOS

Scope Note

Used to indicate a value that should come from a vocabulary (modelled as a `skos:ConceptScheme)

4.1.11. Resource

Property Value

IRI

rdfs:Resource

Preferred Label

Resource

Definition

The class resource, everything

Is Defined By

RDFS

Scope Note

Used to indicate any kind of RDF value - a literal, IRI or Blank Node

4.2. Properties

4.2.1. Properties defined by this model

4.2.2. hasGeocode

Property Value

IRI

addr:hasGeocode

Preferred Label

has geocode

Definition

Indicates that the Address has a Geocode

Is Defined By

This model

Domain

Address

Range

Geocode

4.2.3. Existing properties reused by this model

4.2.4. is name for

Property Value

IRI

cn:isNameFor

Preferred Label

is name for

Definition

Inverse of sdo:name

Is Defined By

CNM

Domain

Compound Name

Range

Feature

Scope Note

Used to link a name to a feature

Example

 
PREFIX addr: <https://linked.data.gov.au/def/addr/>
PREFIX cn: <https://linked.data.gov.au/def/cn/>
PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX sdo: <https://schema.org/>

ex:address-x
    a addr:Address ;
    cn:isNameFor ex:cadastral-object-y ;
.

ex:cadastral-object-y
    a addr:AddressableObject , geo:Feature ;
    sdo:name ex:address-x ;
.

4.2.5. has lifecycle stage

Property Value

IRI

lm:hasLifeCycleStage

Preferred Label

has lifecycle stage

Definition

Indicates a Resources' Lifecycle Stage

Is Defined By

LM

Domain

Resource

Range

Lifecycle Stage

Scope Note

Used to indicate an object’s lifecycle stage

Example

 
PREFIX addr: <https://linked.data.gov.au/def/addr/>
PREFIX ex: <http://example.com/>
PREFIX lm: <https://linked.data.gov.au/def/lifecycle/>
PREFIX sdo: <https://schema.org/>
PREFIX time: <http://www.w3.org/2006/time#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

ex:street-name-x
  a addr:Address ;
  lm:hasLifeCycleStage [
    # this Stage has ceased
    time:hasTime [
      time:hasBeginning [ time:inXSDDate "1982-02-10"^^xsd:date ] ;
      time:hasEnd [ time:inXSDDate "1982-05-11"^^xsd:date ] ;
    ] ;
    sdo:additionalType lm:proposed ;
  ] ,
  [
    # this Stage is still in effect - no hasEnd given
    time:hasTime [
      time:hasBeginning [ time:inXSDDate "1982-05-11"^^xsd:date ] ;
    ] ;
    sdo:additionalType lm:current ;
  ] ;
.

4.2.6. value

Property Value

IRI

rdf:value

Preferred Label

value

Definition

Idiomatic property used for structured values

Is Defined By

RDF

Scope Note

Used to indicate literal or object values for Compound Name objects

Example

 
PREFIX addr: <https://linked.data.gov.au/def/addr/>
PREFIX apt: <https://linked.data.gov.au/def/address-part-types/>
PREFIX ex: <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sdo: <https://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

ex:street-name-x
    a addr:Address ;
    sdo:hasPart [
        rdf:value 4017 ;
        sdo:additionalType apt:postcode
    ] ,
    [
        rdf:value ex:shorncliffe ;
        sdo:additionalType apt:locality
    ] ;
.

4.2.7. additionalType

Property Value

IRI

sdo:additionalType

Preferred Label

additionalType

Definition

An additional type for the item, typically used for adding more specific types from external vocabularies

Is Defined By

SDO

Scope Note

Used to indicate a subtype for Address Part and Addressable Object instances

4.2.8. hasPart

Property Value

IRI

sdo:hasPart

Preferred Label

has part

Definition

Indicates a part of a whole

Is Defined By

SDO

Scope Note

Used to indicate the parts of a Address

4.2.9. hasGeometry

Property Value

IRI

geo:hasGeometry

Preferred Label

has geometry

Definition

A spatial representation for a given Feature

Is Defined By

GEO

Domain

Feature

Range

Geometry

Scope Note

Used to indicate the Geometry of a Feature, such as an Addressable Object

5. Supporting Vocabularies

This model uses many vocabularies to give specialised types and roles to classes. This section previews some vocabularies that may be used and links to some others.

This section is not to be taken as normative: these are example vocabularies and, even then, only part of them, to assist with model use.

When implementing this model, it is within the remit of implementation-specific validators to mandate certain vocabularies and perhaps subsets fo concepts within those vocabularies, for use.

5.1. Vocabularies previewed here

Those defined here are:

Note
 Hyperlinks to these vocabularies will be provided as soon as persistent identifiers for them are issued. Until then, the content of these vocabularies can be found within the submission to register them: https://github.com/GeoscienceAustralia/icsm-vocabs/pull/13/files.

5.1.1. Address Part Types

This vocabulary is an extended version of ISO19160-1's Address Component Type vocabulary and is maintained outside this model. This means it can be extended by the user community (Australian & New Zealand), as needed, and without change to this model.

The vocabulary is located online at:

The original 8 concepts from ISO19160-1 are:

IRI Preferred Label Definition Deprecation note

aptiso:addressedObjectIdentifier

addressed object identifier

Identifier of the addressed object, e.g. building name or address number

Handled by Address/AddressableObject relation

aptiso:administrativeAreaName

administrative area name

Name of an administrative area

Use apt:stateOrTerritory

aptiso:countryCode

country code

ISO 3166-1 code for the country, territory, or area of geopolitical interest

Use apt:country to refer to a Country object

aptiso:countryName

country name

Name of a country

Handled by use of apt:country

aptiso:localityName

locality name

Name of a locality

Use apt:locality to refer to a Locality object

aptiso:postOfficeName

post office name

Name of a post office

Not in current Australian address use

aptiso:postcode

postcode

Code used for the sorting of mail

Use apt:postcode

aptiso:thoroughfareName

thoroughfare name

Name of a thoroughfare

Use apt:street to refer to a street object

These concepts have all been modified or completely replaced, except postcode. Replacements preference links to other complex objects, rather than simple literal data types, for example ISO19160-1’s countryCode which indicates a text code value for a country has been replaced with apt:country which indicates a country object. The use of object references rather than literal values allows for element labelling variation, such as use of abbreviated forms of a name, e.g. "USA" instead of "United Stated of America" , or different language variants, e.g. "Deutschland" instead of "Germany", where the variant information is stored as part of the object referred to.

This vocab currently (June 2024) contains terms such as the following (not the complete vocabulary):

IRI Preferred Label Definition Scope Note

apt:geographicalObject

geographical name object

A reference to a geographical object

This replaces several ISO19160-1 & GNAF values as this reference can be used to any category of Geographical Object with the name for the object used within the address this part is part of. Geographical Object categories are assgned to the Geographical Object, not any part of this address part or the address it is part of.

apt:subaddressType

sub-address type

The type of the sub-address part

Replaces GNAF’s flatTypeCode

apt:subaddressNumber

sub-address number

The number of the sub-address part

Replaces GNAF’s flatNumber

apt:subaddressNumberPrefix

sub-address number prefix

Replaces GNAF’s flatNumberPrefix

apt:subaddressNumberSuffix

sub-address number suffix

Replaces GNAF’s flatNumberSuffix

…​

…​

…​

…​

apt:locality

locality

A reference to a Locality object

Replaces ISO19160-1’s localityName

apt:waterFeature

water feature

A reference to a Water Feature object

New in this model

…​

…​

…​

…​

5.1.2. Address Lifecycle Stage Types

This vocabulary is currently as per ISO19160-1's AddressLifecycleStage vocabulary, however it is expected that this vocabulary will be extended early in its use in Australia/NZ as it is know that jurisdictions within ANZ use other statuses

The Persistent web identifier for this vocabulary is:

IRI Preferred Label Definition

als:current

current

The address is recognised by the authoritative jurisdiction and is in use

als:reserved

reserved

The address is recognised by the authoritative jurisdiction but is not yet in use

als:retired

retired

The address was recognised by the authoritative jurisdiction but is no longer in use

als:proposed

proposed

The address has been suggested for use but not yet accepted

als:rejected

rejected

The address has been ruled not for use

als:unknown

unknown

The stage of this Address' life is unknown therefore it is assumes as a form of unofficial

5.1.3. Geocode Type

This vocabulary was derived from the geocode types given as reference values in the [GNAF].

This is only a partial rendering of the vocabulary - a static list of the top concepts as they were in June, 2023 - provided to give an indicate of values, not to be an exhaustive list of values.

The Persistent web identifier for this vocabulary is:

IRI Preferred Label Definition

gt:building-access-point

Building Access Point

Point of access to the building

gt:building-centroid

Building Centroid

Point as centre of building and lying within its bounds (e.g. for u-shaped building)

gt:centreline-dropped-frontage

Centreline Dropped Frontage

A point on the road centre-line opposite the centre of the road frontage of an address site

gt:driveway-frontage

Driveway Frontage

Centre of driveway on address site frontage

gt:emergency-access

Emergency Access

Specific building or address site access point for emergency services

gt:emergency-access-secondary

Emergency Access Secondary

Specific building or address site secondary access point for emergency services

gt:front-door-access

Front Door Access

Front door of building

gt:frontage-centre

Frontage Centre

Point on the centre of the address site frontage

gt:frontage-centre-setback

Frontage Centre Setback

A point set back from the centre of the road frontage within an address site

gt:letterbox

Letterbox

Place where mail is deposited

gt:property-access-point

Property Access Point

Access point (centre of) at the road frontage of the address site

gt:property-access-point-setback

Property Access Point Setback

Centre of driveway on address site frontage

gt:property-centroid

Property Centroid

Point of centre of parcels making up an address site and lying within its boundaries (e.g. for l-shaped address site)

gt:service-connection-point

Service Connection Point

The utility connection point (e.g. box, or underground chamber)

gt:service-meter

Service Meter

The utility meter (e.g. box, or underground chamber)

gt:unit-centroid

Unit Centroid

Point at centre of unit and lying within its bounds (e.g. for u-shaped unit)

5.2. Links to other vocabularies

Multiple vocabularies derived from existing standards' codelists and databases' lookup table have been created for use with this model and proposed for adoption in vocabulary form to the Intergovernmental Committee on Surveying & Mapping (ICSM). Thos vocabularies, such as Address Status Type, Level Types etc. can be seen online at:

See all the vocabularies with Theme: Geocoded Addressing

Annex A: Requirements

the 10 major requirements for Australian and New Zealand address models, as per the Intergovernmental Committee on Surveying and Mapping established an Addressing 2035 Strategy's Addendum are:

  1. Better complex / multi address representation

  2. Shared addressable object / address conception

  3. Model interoperability

  4. Model profiling and mapping

  5. International model uptake

  6. New address dimensions

  7. Enhanced address life-cycle management

  8. Address validation at creation point

  9. Verifiable model conformance

  10. Multi-lingual and alternate name addressing

Next follows a description per Requirement as to how this Model addresses it.

A.1 Better complex / multi address representation

The Model allows for any number of levels of sub-addressing and anchors the Addressable Objects to items in other systems (e.g. Cadastral databases) so any form of complex address scenario can be represented via a combination of Address and/or Addressable Object relations

A.2 Shared addressable object / address conception

This Model inherits the Address / Addressable Object pattern from the Compound Naming Model CNM which it profiles.

A.3 Model interoperability

The Model is implemented in the general-purpose Web Ontology Language and is thus compatible with all RDF & SPARQL systems.

The model profiles a number of common, general-purpose, Semantic Web models, such as GeoSPARQL (spatiality), OWL-TIME (temporality), PROV (provenance / process flow), schema.org (general-purpose description) and thus is compatible with other models that profile these too.

Some of this Model’s key patterns are inherited from the stand-alone Compound Naming CNM and Lifecycle LM models which other models may also inherit from leading to interoperability on those patterns.

A.4 Model profiling and mapping

The profiling mechanism this Model uses to inherit from well-known international standard models and also special-purpose models may be reused for other models to profile this model.

The model is published as a Profiles Vocabulary profile with profile elements that assist with the development of profiles of this model, for example, separately-published codelists as vocabularies which may be extended or constrained.

Due to this model inheriting from standard models, it may adopt mapping from them to others, for example, GeoSPARQL’s mapping to the ISO Simple Features model ISO19125-1.

A.5 International model uptake

This Model profiles multiple international models – both general-purpose and domain-specific – in particular it profiles ISO 19160-1: Addressing ISO19160-1.

A.6 New address dimensions

This Model uses the modelling Open World Assumption within the context of the Semantic Web, meaning that the model may be extended in any direction, as long as the extension doesn’t invalidate existing model rules.

A.7 Enhanced address life-cycle management

This Model inherits from the Lifecycles Model LM and allows lifecycles to be applied to any model class such as Address, Addressable Object, Address Component.

The stages of the Lifecycle Model are defined by vocabularies thus any implementer may extend or constrain available stages to suite their purpose.

A.8 Address validation at creation point

One resource within the set that make up this model is a canonical validator that can be used to ’validate any data claiming conformance to this Model. Additionally, further validators may be created for this model that either implementing special-purpose validators may be created, for example, for validation of partial addresses.

A.9 Verifiable model conformance

As per A.8, an implementor may choose to implement multiple versions of conformance by implementing multiple validators.

A.10 Multi-lingual and alternate name addressing

The Model allows for both the implementation of literal and complex objects’ annotations (names and descriptions) in language-specific model elements which may then be selected as appropriate.

Additionally, addresses are exported from this model using templates that may both select specific language versions of address elements and implement further logic such as word contractions, as needed.

Annex B: Validation

This model is a conceptual model for addressing (see Address part templating for model type details) and implementers of it are expected to create validators for use with it that test data according to their business rules. Implementers may, for example, test to see whether their data uses particular values for particular vocabularies or that geocodes are within a certain distance of the boundary of the Addressable Object.

The validation system proposed for use with this model is the Shapes Constraint Language (SHACL) SHACL which implements validators for RDF data.

B.1 Example Validators

Two example validators are provided with this model:

  1. validator.ttl - a canonical validator for this model

    1. Test that every Address indicates: an Addressable Object with cn:isNameFor; a Geocode with addr:hasGeocode; at least one part, that is a Compound Name, with sdo:hasPart

  2. validator-qld.ttl a validator for a jurisdiction - Queensland

    1. Test that every Address indicates at least 3 parts

B.2 Performing validation

The validators given above may be applied to RDF data implementations of this model using any one of a number of tools such as any in this list:

Annex C: Templating

To present - on screen or in print form - consolidated address information, such as for an envelope, the address parts need to be assembled in a particular order and perhaps processes to make contractions etc. The logic for this is not contained in core model itself but must be implemented in application code reflecting business logic, as in what it is that implementers need to implement!

This templating annex gives a demonstration of basic templating however users of this model are free to implement their own templates and template logic to suit their needs.

Generating names

Consider the example address:

Unit 4B, 72 Yundah Street
Shorncliffe, Queensland
4017 Australia

The "print out" format is as above where the Address parts, as per Queensland’s implementation are:

Part Value

Unit

"4B"

StreetNumber

"72"

Street

reference to the Yundah Street, street object

Locality

reference to the Shorncliffe locality object

StateOrTerritory

reference to the Queensland state object

Postcode

"4017"

Country

reference to the Australia state object

Using Feature Naming recursive logic - generating names for the Street, Locality, State & Country objects elsewhere, the address model sees the following:

Part Value

Unit

"4B"

StreetNumber

"72"

Street

"Yundah Street"

Locality

"Shorncliffe"

StateOrTerritory

"Queensland"

Postcode

"4017"

Country

"Australia"

Thus, an informal template for the example address, given these values could be:

Unit {Unit}
{StreetNumber} {Street}
{Locality}, {StateOrTerritory}
{Postcode} {Country}

This is an informal logic - no formalised templating syntax is used - but it’s obvious to see that you’d place the value "Shorncliffe" where the marker {Locality} exists in the informal template.

Such an informal template will not work for comprehensive address templates as it doesn’t include many potential address parts, such as Unit/Flat information, contractions, building names etc.

The next two subsections use a formal templating logic that can be extended for any level of template coverage/complexity.

Basic Template

This template assembles the parts of an Address in a basic manner, similar to the example in the previous section, and something like this is expected to be the commonly used.

The template, in EBNF form ISO-IEC-14977, is:

space = " "
comma = ","
letters = "A" | "B" | "C" | "D" | "E" | "F" | "G"
       | "H" | "I" | "J" | "K" | "L" | "M" | "N"
       | "O" | "P" | "Q" | "R" | "S" | "T" | "U"
       | "V" | "W" | "X" | "Y" | "Z" | "a" | "b"
       | "c" | "d" | "e" | "f" | "g" | "h" | "i"
       | "j" | "k" | "l" | "m" | "n" | "o" | "p"
       | "q" | "r" | "s" | "t" | "u" | "v" | "w"
       | "x" | "y" | "z" ;
extra_characters = | " " | "-" ;
numbers = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
extended_letters = letters | extra_characters ;
extended_numbers = numbers | extra_characters ;
extended_letters_and_numbers = extended_letters | extended_numbers

geographical_object_name = extended_letters_and_numbers
level_number = extended_numbers ;
level = "Level" space level_number
unit_indicator = "Unit" space
subaddress_number_prefix = extended_letters
subaddress_number_number = extended_numbers
subaddress_number_suffix = extended_letters
street_number_prefix = extended_letters
street_number_number = extended_numbers
street_number_suffix = extended_letters
street_label = extended_letters_and_numbers

locality = extended_letters
state_or_territory = extended_letters
country = extended_letters
postcode = numbers

subaddress = level unit_indicator subaddress_number_prefix subaddress_number subaddress_number_suffix
street = street_number_prefix street_number street_number_suffix space street_label

address = geographical_object_name NEWLINE
          subaddress NEWLINE
          street NEWLINE
          locality, space state_or_territory NEWLINE
          postcode country

Part values for the example above, using these EBNF tokens are:

Token Value

building_name

"The Manse"

property_name

-

level

-

subaddress_number

"4"

subaddress_number_suffix

"B"

street_number

"72"

street_name

"Yundah Street"

locality

"Shorncliffe"

state_or_territory

"Queensland"

postcode

"4017"

country

"Australia"

The template would result in this the same "print out" value as per the example in the section above:

The Manse
Unit 4B
72 Yundah Street
Shorncliffe, Queensland
4017 Australia

Short Form Template

This Short Form Template is an example of an alternative template to the Basic Template above.

This template uses most of the same layout logic as the Basic Template but it replaces NEWLINE between building_name & property_name with space and makes the following contractions:

  • "Level X" → Lv X

  • "Unit X," → "X/"

It contracts States & Territories as follows:

  • "Australian Capital Territory" → "ACT"

  • "New South Wales" → "NSW"

  • "Northern Territory" → "NT"

  • "Queensland" → "ACT"

  • "South Australia" → "SA"

  • "Tasmania" → "TAS"

  • "Victoria" → "VIC"

  • "Western Australia" → "WA"

It contracts Countries as follows:

  • "Australia" → "Aust."

  • "New Zealand" → "NZ"

This template will also see out short form templates implemented for referenced objects, such as Roads so for the example above, using the Roads Model’s short form template[5], the street name "Yundah Street" will be contracted to "Yundah St".

Given these changes, the example above would print out like this:

The Manse
4B/72 Yundah St
Shorncliffe, QLD
4017 Aust.

Annex D: Extended Examples

This model contains some small examples in the definitions tables of individual classes and properties, for example Address.

Additionally, a series of extended examples are provided for Queensland government’s testing within the following repository which lists and describes them:

Bibliography

AS4189:2011

Standards Australia. AS/NZS 4819:2011 Rural and urban addressing

CNM

Australian Government Linked Data Working Group. Compound Naming Model. Semantic Web data model (2023). https://linked.data.gov.au/def/cn

CONNEGP

World Wide Web Consortium, Content Negotiation by Profile, W3C Working Draft (20 March 2022). https://w3c.github.io/dx-connegp/connegp/

GEO

Open Geospatial Consortium, OGC GeoSPARQL - A Geographic Query Language for RDF Data, Version 1.1 (2021). OGC Implementation Specification. http://www.opengis.net/doc/IS/geosparql/1.1

[GNAF]

Geoscape Australia. Geocoded National Address File, G-NAF (2023). https://data.gov.au/dataset/ds-dga-19432f89-dc3a-4ef3-b943-5326ef1dbecc

GN

Queensland Spatial Information. Geographical Names Model (2023). https://linked.data.gov.au/def/gn

ISO-IEC-14977

International Organization for Standardization, ISO/IEC 14977 : 1996(E): Extended Backus–Naur form. International Organization for Standardization (1996). https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf

ISO19101-1

International Organization for Standardization, ISO 19101-1:2014 Geographic information — Reference model — Part 1: Fundamentals (2014)

ISO19125-1

International Organization for Standardization, ISO 19125-1: Geographic information — Simple Feature Access - Part 1: Common Architecture (2004)

ISO19156

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

ISO19160-1

International Organization for Standardization, ISO 19160-1: Addressing Part 1: Conceptual model (2015). https://www.iso.org/standard/61710.html

LM

Australian Government Linked Data Working Group. Lifecycle Model (2023). https://linked.data.gov.au/def/lifecycle

OWL

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, The Profiles Vocabulary, W3C Working Group Note (18 December 2019). https://www.w3.org/TR/dx-prof/

RDF

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

RDFS

World Wide Web Consortium, RDF 1.2 Schema, W3C First Public Working Draft (16 May 2023). https://www.w3.org/TR/rdf12-schema/

ROADS

Queensland Spatial Information. Roads Model (2023). https://linked.data.gov.au/def/roads

SDO

W3C Schema.org Community Group, schema.org. Community ontology (2015). https://schema.org

SHACL

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

SSN

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

SKOS

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

TTL

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

XSD

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

1. See https://en.wikipedia.org/wiki/Semantic_Web for a general description of the Semantic Web
2. The OGC: https://www.ogc.org/
3. See this Wikipedia Data Modeling article for a good starting point to more information
4. https://en.wikipedia.org/wiki/Mereology
5. https://linked.data.gov.au/def/roads#_short_form_template