A Semantic Web data model used for address information

1. Metadata

IRI

https://w3id.org/profile/anz-address

Preferred Label

ANZ National Address Model - Candidate

Definition

This model is a Semantic Web data model used for address information. It caters specifically for Australian & New Zealand’s address modelling needs.

Created

2021-12-16

Modified

2022-06-11

Issued

0000-00-00

Creator

Nicholas J. Car

Publisher

-

Provenance

This ontology was made for the Queensland Department of Resources, Spatial Information unit to assist with 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 and is based primarilty on the ISO19160-1 Addressing Part 1: Conceptual model with additional elements from a small set of well-regarded Semantic Web models such as GeoSPARQL and SKOS. It is also informed by the relational databalse model used for the G-NAF, Australia’s Geocoded National Address File, and CSIRO work in 2018 to characterise the GNAF in Sematic Web form, the ontlogy for which is online at https://linked.data.gov.au/def/gnaf.

Status

Early draft

Version

addr:0.0.1

Code Repository

https://nicholascar.com/anz-nat-addr-model-candidate

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Copyright

© Nicholas J. Car, 2022

Machine-readable form (RDF)

https://w3id.org/profile/anz-address.ttl

2. Preamble

2.1. Abstract

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

This model is a Semantic Web data model used for address information. It caters specifically for Australian & New Zealand’s address modelling needs. It was originally was made for the Queensland Department of Resources, Spatial Information unit, to assist with 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 and is based primarilty on the ISO19160-1 Addressing Part 1: Conceptual model [ISO19160-1] with additional elements from a small set of well-regarded Semantic Web models such as GeoSPARQL [GEO] and SKOS [SKOS]. It is also informed by the relational databalse model used for the G-NAF, Australia’s Geocoded National Address File, and CSIRO work in 2018 to characterise the GNAF in Sematic Web form, the ontlogy for which is online at https://linked.data.gov.au/def/gnaf.

2.2. Namespaces

This model is built on a small set of well-regarded Semantic Web models which use a variatey of namespaces. Prefixes for this namespaces, used througout this document, are listed below.

Prefix Namespace Description

addr:

https://w3id.org/profile/anz-address/

Placeholder namespace for this model

role:

https://w3id.org/profile/anz-address/AddressRoleType/

Placeholder for the Address Roles Vocabulary

asgsed3:

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

Australian Statistical Geographies Standard Dataset, Release 3

dcterms:

http://purl.org/dc/terms/

Dublin Core Terms vocabulary namespace

ex:

http://example.com/thing

Generic examples namespace

geo:

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

OGC GeoSPARQL

isov1:

http://def.isotc211.org/iso19160/-1/2015/Address/code/AddressComponentType/

[ISO19160-1]'s AddressComponentType vocabulary namespace

isov2:

https://w3id.org/profile/anz-address/AddressLifecycleStageType/

[ISO19160-1]'s AddressLifecycleStage vocabulary namespace

isov3:

https://w3id.org/profile/anz-address/AddressStatusType/

[ISO19160-1]'s AddressStatus vocabulary namespace

owl:

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

Web Ontology Language ontology namespace

rdfs:

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

RDF Schema ontology namespace

sosa:

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

Sensor, Observation, Sample, and Actuator ontology namespace

skos:

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

Simple Knowledge Organization System (SKOS) ontology namespace

time:

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

Time Ontology in OWL namespace

void:

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

Vocabulary of Interlinked Data (VoID) ontology namespace

xsd:

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

XML Schema Definitions ontology namespace

2.3. Conformance

This model conforms to the OntPub Profile which is a specification for ontology publication that mandates certain structural and metadata properties for the model as a whole and model elements. Metadata elements for the model as a whole - the ontology - are given in the Metadata section above.

2.3.1. Figures

Figures used in this document use the following key:

key
Figure 1. 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 in the Turtle syntax.

3. Introduction

In 2021, the 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. It did not present an address model.

This model is created with alignment to the Addressing 2035 Strategy as a high priority, so it’s use aims to address Pain Points identified in the Strategy.

The model is mostly an based on the structures of International Addressing standard, ISO19160-1, but this model is expressed in Semantic Web form. Unlike ISO19160-1, this model also re-uses elements from other, well-known, Semantic Web models, as is the Semantic Web norm.

This model does not model all of address data managers' concerns: it leaves things like the detailed modellign os spatial information to other models or extensions to this model. Also, by reusing elements from well-known Semantic Web models, this model has many "pick-up" points that can be used to join other information on to. For example, the Resource indicated as an Address Component value, may be a locally-defined simple value type - a number or string - but it may also be a complex object defined elsewhere, such as a Locality.

3.1. Model resources

This document is this model’s "Specification" which is its authoratitive, 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 used by this model

[Annex A: Validator] & Validator

Validation

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

[Annex B: Examples] & Example data files

Example

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

Annex C: Demo Implementations

Example

Demonstration implementations of this model in various database forms

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 golbal identity, that can be used in isolation as well as together. This is in contrast to Unified Modelling Language (UML) Class Diagrams which treat Properties as sub-parts of particular classes.

This model defines some Classes and Properties and also requires certain existing Cs & Ps for reuse. All Cs & Ps in this model, both defined and reused, are listed here with an indication of where the element is difined given in the Is Defined By field.

overview
Figure 2. An informal Model Overview diagram showing the major elements of this model
upper classes
Figure 3. Mapping of the main model classes to common Semantic Web classes

4.1. Classes

4.1.1. Address

Property Value

IRI

addr:Address

Preferred Label

Address

Definition

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

Is Defined By

ANZ National Address Model

Sub-class Of

geo:Feature

Provenance

Derived from [ISO19160-1]'s Address class

Expected Properties

is address for, has address component, has address role, has lifecycle stage

Example

ex:addr-1
  a addr:Address ;
  addr:isAddressFor <some-external-object> ;
  addr:hasAddressComponent
    [
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
    [
      addr:hasValue "Oxford" ;
      addr:hasComponentType addrct:thoroughfareName ;
    ] ,
    [
      addr:hasValue strt:Place ;
      addr:hasValueText "Place" ;
      addr:hasComponentType addct:StreetType ;
    ] ,
    [
      addr:hasValue <LGA2021/1234> ;
      addr:hasValueText "Shorncliffe" ;
      addr:hasComponentType addrct:locality ;
    ] ,
    [
      addr:hasValue <STE2021/6> ;
      addr:hasValueText "Queensland" ;
      addr:hasComponentType addct:StateOrTerritory ;
    ] ,
    [
      addr:hasValue <AUS2021/AUS> ;
      addr:hasValueText "Australia" ;
      addr:hasComponentType addct:Nation ;
    ] ;
.

4.1.2. Addressable Object

Property Value

IRI

addr:AddressableObject

Preferred Label

Addressable Object

Definition

An object that is unambiguously determined by an address.

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

Is Defined By

ANZ National Address Model

Sub-class Of

geo:Feature

Provenance

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

Scope note

Judgement as to what makes for a permissable 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

has address, geo:hasGeometry

Example

# ex:parcel-x is inferred to be an Addressable object
# due to the property addr:hasAddress indicated for it
ex:parcel-x addr:hasAddress ex:addr-1 .

# this object is declared to be an Addressable Object
<http://example.com/building/y>
  a addr:AddressableObject ;
  rdfs:label "Building Y" ;
.

# ex:admin-area-z is inferred to be an Addressable Object
# due to the property addr:isAddressFor indicating it
ex:addre-2 addr:isAddressFor ex:admin-area-z .

4.1.3. Address Component

Property Value

IRI

addr:AddressComponent

Preferred Label

Address Component

Definition

A component that is a constituent part of an address

Is Defined By

ANZ National Address Model

Sub-class Of

rdfs:Resource

Provenance

Derived from [ISO19160-1]'s AddressComponent class

Scope note

Address Components can be literals - numbers, words etc. - or complex ojects - Localities, districtes etc. If the Address Component is a complex object, a textual representation of it must be provided when a textual rendering of all of an Addresses' component are required, for example for letter printing.

Complex objects are preferred for use over literals when the object referred to has independent identity.

Ordering of Address Components, for example for letter printing, is not fixed within this model but should be implemented with a positioning preference system utilising the Address Component’s addr:hasComponentType values which should come from a controlled vocabulary of Address Component Type values.

Expected Properties

has value, has value text, [hasComponentType]

Example

ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent
    [
      # a simple numerical literal - street number
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
    [
      # a simple literal - street name
      addr:hasValue "Oxford" ;
      addr:hasComponentType addrct:thoroughfareName ;
    ] ,
    [
      # complex object - a Locality
      addr:hasValue <http://example.com/lga/1234> ;
      # textual value of complex object
      addr:hasValueText "Shorncliffe" ;
      addr:hasComponentType addrct:locality ;
    ] ,
    ...

4.1.4. Address Component Type

Property Value

IRI

addr:AddressComponentType

Preferred Label

Address Component Type

Definition

Code that specifies the kind of address component

Is Defined By

ANZ National Address Model

Sub-class Of

skos:Concept

Provenance

Derived from [ISO19160-1]'s AddressComponent class

Scope note

An Address Component’s type should be indicated with values from a controlled vocabulary - a code list.

A SKOS vocabulary of Address Component Types is suplied with this ontology.

Expected Properties

Standard properties for a SKOS Concept

Example

ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent
    [
      # "StreetNumber" type
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
    [
      # "StreetName" type
      addr:hasValue "Oxford" ;
      addr:hasComponentType addrct:thoroughfareName ;
    ] ,
    [
      # "Locality" type
      addr:hasValue <http://example.com/lga/1234> ;
      # textual value of complex object
      addr:hasValueText "Shorncliffe" ;
      addr:hasComponentType addrct:locality ;
    ] ,
    ...

4.1.5. Address Lifecycle Stage

lifecycle stages
Figure 4. An example Address, QLD186906, with Lifecycle Stages
Property Value

IRI

addr:AddressLifecycleStage

Preferred Label

Address Lifecycle Stage

Definition

Represents the different lifecycle stages of an Address

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s AddressLifecycle class

Scope note

An Address Lifecycle Stage’s type should be indicated with values from a controlled vocabulary - a code list.

A SKOS vocabulary of Address Lifecycle Stages is suplied with this ontology.

In this model, these Lifecycle Stages are defined for use with Addresses only, not also Address Components, as per ISO19160-1.

Expected Properties

Standard properties for a SKOS Concept

Example

# An Address with two Lifecycle Stages indicated:
# one current and one past
ex:addr-1
  a addr:Address ;
  addr: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 ] ;
    ] ;
    dcterms:type addrls:proposed ;
  ] ,
  [
    # this Stage is still in effect - no hasEnd given
    time:hasTime [
      time:hasBeginning [ time:inXSDDate "1982-05-11"^^xsd:date ] ;
    ] ;
    dcterms:type addrls:current ;
  ] ,
.

# The Address Lifecycle Stage 'proposed'
# from the Address Lifecycle Stage Types vocabulary
# indicating only some properties
addrls:proposed
    a skos:Concept ;
    ...
    skos:prefLabel "Proposed" ;
.

4.1.6. Address Lifecycle Stage Type

Property Value

IRI

addr:AddressLifecycleStageType

Preferred Label

Address Lifecycle Stage Type

Definition

Code that specifies the kind of Address Lifecycle Stage

Is Defined By

ANZ National Address Model

Sub-class Of

skos:Concept

Provenance

Derived from [ISO19160-1]'s AddressLifecycle class

Scope note

An Address Address Lifecycle Stage’s type should be indicated with values from a controlled vocabulary - a code list.

A SKOS vocabulary of Address Lifecycle Stage Types is suplied with this ontology.

Expected Properties

Standard properties for a SKOS Concept

Example

# An Address with a Lifecycle Stages indicated
# which then indicates its type
ex:addr-1
  a addr:Address ;
  addr:hasLifeCycleStage [
    ...
    dcterms:type addrls:proposed ;
  ] ;
  ...
.

4.1.7. Address Role

Property Value

IRI

addr:AddressRole

Preferred Label

Address Role

Definition

AddressRole represents a task for which this Address may be used

Is Defined By

ANZ National Address Model

Sub-class Of

skos:Concept

Provenance

Derived from [ISO19160-1]'s AddressPosition & AddressPositionType classes

Scope note

ISO19160-1 does not contain an AddressRole class but instead an AddressPosition class with positioning and role properties. This Standard make role a direct property of Address instead and provides for a positional qualifier (qualified against the position of the AddressableObject) instead to allow whole addresses to carry role tasking.

Expected Properties

Standard properties for a SKOS Concept

Example

# An Address with two roles
ex:addr-1
  a addr:Address ;
  addr:hasAddressRole
    ex:emergencyAccess ,
    buildingAccessPoint ;
    ...

4.1.8. Geocode

Property Value

IRI

addr:Geocode

Preferred Label

Geocode

Definition

A Feature used to position other Features and to carry typing or provenance of that position

Is Defined By

ANZ National Address Model

Sub-class Of

geo: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 or must also be located by ference to an Addressable Object which has a Geometry, depending on business rules.

Expected Properties

dcterms:type - to indicate a type, as per the Geocode Type vocabulary

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.9. Geocode Type

Property Value

IRI

addr:GeocodeType

Preferred Label

Geocode Type

Definition

The type of Geocode, typically determined by creation method

Is Defined By

ANZ National Address Model

Sub-class Of

skos:Concept

Provenance

Derived from the G-NAF’s Geocode Type codelist

Expected Properties

Standard properties for a SKOS Concept

Example

# An Address with a Geocode with its type given (geocodeType:DF)
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.2. Properties

4.2.1. is address for

Property Value

IRI

addr:isAddressFor

Preferred Label

is address for

Definition

Indicates an Addressable Object that an Address is allocated to

Is Defined By

ANZ National Address Model

Sub-property Of

rdfs:label

Inverse Of

has address

Provenance

Derived from [ISO19160-1]'s object relations

Domain

Address

Range

Addressable Object

Example

# the Address ex:addr-1 is allocated to
# some-addressable-object
ex:addr-1
  a addr:Address ;
  addr:isAddressFor <some-addressable-object> ;
.

4.2.2. has address

Property Value

IRI

addr:hasAddress

Preferred Label

has address

Definition

Indicates an Address has been allocated for an Addressable Object

Is Defined By

ANZ National Address Model

Inverse Of

is address for

Provenance

Derived from [ISO19160-1]'s object relations

Domain

Addressable Object

Range

Address

Example

# the addr:AddressableObject, some-addressable-object,
# indicates an address with addr:hasAddress
<some-addressable-object>
  a addr:AddressableObject ;
  addr:hasAddress ex:addr-1 ;
.

ex:addr-1
  a addr:Address ;
.

4.2.3. has address component

Property Value

IRI

addr:hasAddressComponent

Preferred Label

has address component

Definition

Indicates an Address Component of an Address

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s object relations

Domain

Address

Range

Address Component

Example

# an Address has an Address Component, a street number, indicated
ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent [
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
...

4.2.4. has address component type

Property Value

IRI

addr:hasAddressComponentType

Preferred Label

has address component type

Definition

Indicates an Addresses Component’s type

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s object relations

Domain

Address Component

Range

Address Component Type

Example

# an Address has an Address Component with its type,
# street number, indicated
ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent [
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
...

4.2.5. has address role

Property Value

IRI

addr:hasAddressRole

Preferred Label

has address component type

Definition

Indicates an Address Role for an Address

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s AddressPosition class and properties

Domain

Address

Range

Address Role

Example

# An Address with two roles
ex:addr-1
  a addr:Address ;
  addr:hasAddressRole
    ex:emergencyAccess ,
    buildingAccessPoint ;
    ...

4.2.6. has geocode

Property Value

IRI

addr:hasGeocode

Preferred Label

has geocode

Definition

Indicates a refined, that is a very accurate or specific, geometry, usually a point, for an Address qualified by the Geocode Type - how it was generated.

Is Defined By

ANZ National Address Model

Provenance

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

Scope Note

This property, along with hasRole, allows multiple Addresses with different locations to be allocated to Addressable Objects and for those addresses to be used for different purposes. The location indicated by this property should be within/on/next to the location of the Addressable Object this Address is for, within some acceptable tolerance.

Domain

Address

Range

Geocode

Example

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

4.2.7. has lifecycle stage

Property Value

IRI

addr:hasLifecycleStage

Preferred Label

has lifecycle stage

Definition

Indicates an Addresses' Lifecycle Stage

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s object relations

Domain

Address

Range

Address Lifecycle Stage

Example

# An Address with two Lifecycle Stages indicated:
# one current and one past
ex:addr-1
  a addr:Address ;
  addr: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 ] ;
    ] ;
    dcterms:type addrls:proposed ;
  ] ,
  [
    # this Stage is still in effect - no hasEnd given
    time:hasTime [
      time:hasBeginning [ time:inXSDDate "1982-05-11"^^xsd:date ] ;
    ] ;
    dcterms:type addrls:current ;
  ] ,
.

4.2.8. has value

Property Value

IRI

addr:hasValue

Preferred Label

has value

Definition

Indicates the value of an Address Component

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s AddressComponent object’s properties

Domain

Address Component

Range

rdfs:Resource (IRI or literal)

Example

ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent
    [
      # "StreetNumber" type
      addr:hasValue 20 ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
    [
      # "StreetName" type
      addr:hasValue "Oxford" ;
      addr:hasComponentType addrct:thoroughfareName ;
    ] ,
    [
      # "Locality" type
      addr:hasValue <http://example.com/lga/1234> ;
      # textual value of complex object
      addr:hasValueText "Shorncliffe" ;
      addr:hasComponentType addrct:locality ;
    ] ,
    ...

4.2.9. has value text

Property Value

IRI

addr:hasValueText

Preferred Label

has value

Definition

Indicates the textual rendering of an Address Component

Scope note

This property is to be used to represent the textual value of Address Components that are literals and also complex objects. For a literal, the same value will be present for hasValue and hasValueText, e.g. a street number of 20 or a property name of "Bonnie Doon", however for a complex object, e.g. the locality http://example.com/lga/1234, a textual representation of it must be selected. Likely a simple name for the object will do, i.e. a Locality name or a Street Locality name.

Is Defined By

ANZ National Address Model

Provenance

Derived from [ISO19160-1]'s AddressComponent object’s properties

Domain

Address Component

Range

xsd:string

Example

ex:addr-1
  a addr:Address ;
  addr:hasAddressComponent
    [
      # "StreetNumber" type
      addr:hasValue 20 ;
      addr:hasValueText "20" ;
      addr:hasComponentType addrct:streetNumber ;
    ] ,
    [
      # "StreetName" type
      addr:hasValue "Oxford" ;
      addr:hasValueText "Oxford" ;
      addr:hasComponentType addrct:thoroughfareName ;
    ] ,
    [
      # "Locality" type
      addr:hasValue <http://example.com/lga/1234> ;
      # textual value of complex object
      addr:hasValueText "Shorncliffe" ;
      addr:hasComponentType addrct:locality ;
    ] ,
    ...

5. Supporting Vocabularies

This model has several classes that are subclasses of the generic vocabulary/taxonomy item class skos:Concept. The classes are:

Individuals of these classes must be instances of the particular class and must also be Concepts selected from controlled vocabularies of instances.

This profile contains vocabularies for these class types derived from [ISO19160-1]. Ceoncepts in these vocabularies are from the standard plus additions specified for ANZ.

Concepts from vocabularies other than those specified here may be use with this model as long as the vocabulary items are dual-classed as skos:Concept and the relevant model class, e.g. addr:AddressComponentType.

Note
The representations of vocabularies here do not contain full vocabulary information such as concept hierarchy. Please see the vocabularies' own documentation for full details.

5.1. Address Component Types Vocabulary

This vocabulary is an extended version of [ISO19160-1]'s AddressComponentType vocabulary. The original 9 concepts from the standard are included however only two of them - locality & postcode - are suggested for use. 19 additional concepts are taken from address elements in the G-NAF, such as numberFirstSuffix. Additional concepts are added as needed to cater for futher ANZ addressing needs, such as traditionalPlaceName to cater for First Nations place naming.

IRI Label Definition Status Notes

isov1:addressedObjectIdentifier

addressed object identifier

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

original

Do not use: handles by Address/AddressableObject relation

isov1:administrativeAreaName

administrative area name

Name of an administrative area

original

Do not use: handled by object references, not text name

isov1:countryCode

country code

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

original

N/A for Aust. addresses

isov1:countryName

country name

Name of a country

original

N/A for Aust. addresses

isov1:locality

locality

A reference to a locality object

original

Used in G-NAF

isov1:postOfficeName

post office name

Name of a post office

original

Do not use

isov1:postcode

postcode

Code used for the sorting of mail

original

Used in G-NAF

isov1:thoroughfareName

thoroughfare name

Name of a thoroughfare

original

Do not use, use isov1:streetLocality

isov1:thoroughfareType

thoroughfare type

Type of a thoroughfare. Must be selected from a controlled vocabulary

original

Do not use, use isov1:streetLocality

isov1:buildingName

ANZ addition

Used in G-NAF

isov1:lotNumberPrefix

ANZ addition

Used in G-NAF

isov1:lotNumber

The reference number allocated to a property for subdivision administration purposes prior to road numbering

ANZ addition

Used in G-NAF

isov1:lotNumberSuffix

ANZ addition

Used in G-NAF

isov1:flatTypeCode

ANZ addition

Used in G-NAF

isov1:flatNumberPrefix

ANZ addition

Used in G-NAF

isov1:flatNumber

ANZ addition

Used in G-NAF

isov1:flatNumberSuffix

ANZ addition

Used in G-NAF

isov1:levelTypeCode

ANZ addition

Used in G-NAF

isov1:levelNumberPrefix

ANZ addition

Used in G-NAF

isov1:levelNumber

ANZ addition

Used in G-NAF

isov1:levelNumberSuffix

ANZ addition

Used in G-NAF

isov1:numberFirstPrefix

ANZ addition

Used in G-NAF

isov1:numberFirst

The identifier number of the address in the road or thoroughfare, or the start number for a ranged address

ANZ addition

Used in G-NAF

isov1:numberFirstSuffix

ANZ addition

Used in G-NAF

isov1:numberLastPrefix

ANZ addition

Used in G-NAF

isov1:numberLast

Identifies the last number for a ranged address in the road or thoroughfare

ANZ addition

Used in G-NAF

isov1:numberLastSuffix

ANZ addition

Used in G-NAF

isov1:streetLocality

ANZ addition

Used in G-NAF

isov1:traditionalPlaceName

ANZ Addition

Introduced to cater for expected demand

isov1:propertyName

ANZ Addition

Introduced to cater for complex addresses (gated communities) and rural properties

5.2. Address Lifecycle Stage Types Vocabulary

This vocabulary is an extended version of [ISO19160-1]'s AddressLifecycleStage vocabulary.

IRI Label Definition Status

isov2:current

current

The address or address component is currently in use

original

isov2:proposed

proposed

The address or address component has been proposed, i.e. the relevant authority has initiated approval procedures for the use of the address or address component

original

isov2:rejected

rejected

The address or address component was proposed but rejected

original

isov2:reserved

reserved

The address or address component has been reserved for future use

original

isov2:retired

retired

The address or address component was in use at some stage, but not anymore

original

isov2:unknown

unknown

The lifecycle stage of the address or address component is unknown

original

5.3. Address Role Types Vocabulary

This vocabulary is derived from [ISO19160-1]'s AddressPosition and AddressPositionType classes and an example vocabulary in Annex C of [ISO19160-1] for the latter.

IRI Label Definition Status

role:buildingAccessPoint

building access point

The address that identifies the place to access a building AddressableObject from

original

role:buildingCentroid

building centroid

original

role:emergencyAccess

emergency access

The centrepoint of a Building’s geometry

original

role:propertyCentroid

property centroid

The centrepoint of the Property’s geometry

original

role:serviceConnectionPoint

service connection point

The point at which utility services are connected to an AddressableObject

original

role:streetAddress

street address

A thoroughfare location

addition

role:centroid

centroid

The centrepoint of the AddressableObject’s geometry

addition

5.4. Address Status Types Vocabulary

This vocabulary is an extended version of [ISO19160-1]'s AddressStatus vocabulary.

IRI Label Definition Status

isov3:official

official

An official addressing authority assigned the address

original

isov3:unknown

unknown

The status of the address is unknown

original

isov3:unofficial

unofficial

The address was not assigned by an official addressing authority

original

Annex A: Validators

A.1 Description

Two validators to test data claiming conformance to this model are provided as resources within this profile. The first, validator.ttl is the canonical validator for this model. The second, validator-qld.ttl is a demonstration validator for Queensland that includes extended validator rules building on validator.ttl.

A summary of the canonical validator’s elements ("shapes") is given in Table 1.

Table 1. Shapes within the Canonical Validator
Shape ID Description

val:address-mandatory-properties

Checks the mandatory properties of Address instances: addr:isAddressFor (1), addr:hasAddressComponent (1+), addr:hasGeocode (1+)

val:address-component-properties

Checks the mandatory properties of AddressConponet instances: dcterms:type (1), addr:hasValue (1), addr:hasValueText (1, and that it’s a string literal)

val:address-geocode-properties

Checks the mandatory properties of Geocode instances: dcterms:type (1), at least one of geo:asWKT, geo:asGeoJSON or geo:asGML must be present

val:address-lifecycle-stage-properties

Checks the mandatory properties of LifecycleStage instances: dcterms:type (1), time:hasTime (1)

Note
The canonical validator’s list of elements will almost certainly grow as use of this model fleshes out model element needs.

A.2 Use

These validators are implemented using the Shapes Constraint Language (SHACL) and any tool that support SHACL validation may be used to apply them to data to be validated.

Some examples of such tools are:

Any of those tools may be used to apply the Canonical or Queensland validator to data and produce a report of the validity of the data.

Annex B: Extended Examples

The extended examples for this model are a series of data files stored in this model’s online code repository:

Each file there exemplifies a modelling situation or problem and the modelling within the data gives this model’s solution. The particular situation/problem is explained at the start of each file. For example, in the file locan-01.ttl, we have:

# Logan 1
# Multiple Parcels - 1 Address
#
# Address: 714 Stockleigh Road Stockleigh QLD. Parcels: 378RP849082, 477W31578
# &
# Address: 38 & 40 Augustus Street Kingston. Parcels: 57RP38148 and 57RP38148

where Logan 1 is the example name, Multiple Parcels - 1 Address is the scenario descriptor and the remainder the details of the examples in text.

As per the inline examples in this document, all example data is RDF data represented using the Turtle syntax, as per Conformance.

Annex C: Demo Implementations

Several demonstration implementations of this Address model are given in the code repository containing its content.

C.1 RDF Database Demo

The 15 or so extended examples data files within the code repository (see above Annex for details) represent an implementation of this model for they are formulated in RDF data and are thus able to be loaded into an RDF database (often called a "triplestore") and queried.

To demonstrate this, the multiple example files can be loaded directly into such tools as Apache’s Fuseki database. They can also be combined into one file using RDF tooling and that uploaded. The script _compound_example.py in the examples directory compounds all the examples into the single file _all.ttl.

Once loaded into a triplestore, SPARQL queries can be used to interrogate the data similarly to how SQL queries are used for relational databases. Some example SPARQL queries for the examples data are:

C.1.1 Ordered Address Components

For those Addresses that have components - not all in the example data - this query orders the components as per Queensland norms, including the new Property Name type component at the start.

PREFIX addr: <https://w3id.org/profile/anz-address/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX isov1: <http://def.isotc211.org/iso19160/-1/2015/Address/code/AddressComponentType/>

SELECT ?a ?ac_type ?val ?val_text
WHERE {
    VALUES (?ac_type ?ac_order) {
        (isov1:buildingName 1)
        (isov1:propertyName 2)
        (isov1:traditionalPlaceName 3)
        (isov1:flatTypeCode 4)
        (isov1:flatNumber 5)
        (isov1:numberFirst 6)
        (isov1:streetLocality 7)
        (isov1:locality 8)
        (isov1:postcode 9)
        (isov1:administrativeArea 10)
    }
    ?a a addr:Address ;
        addr:hasAddressComponent [
            dcterms:type ?ac_type ;
            addr:hasValue ?val ;
            addr:hasValueText ?val_text
        ]
}
ORDER BY ?a ?ac_order

This query selects only Address Components of the types given in the VALUES list and orders them as per the integer numbering given. Results for the example address 2/18 Oxford Place (see extended-examples/oxford-place.ttl) are:

?a ?ac_type ?val ?val_text

a:GAQLD161268186

isov1:flatNumber

"2"^^xsd:integer

"2"

a:GAQLD161268186

isov1:numberFirst

"18"^^xsd:integer

"18"

a:GAQLD161268186

isov1:streetLocality

sl:QLD140492

"Oxford Place"

a:GAQLD161268186

isov1:locality

l:loc38f189794e03

"Shorncliffe"

C.1.2 Selecting addresses by geocode type and in an area

The following query selects addresses from the examples that have a Geocode of type Property Access Point (PAP) and that are within the Bounding Box of 154 -27, 154 -28, 153 -28, 153 -27, 154 -27.

PREFIX addr: <https://w3id.org/profile/anz-address/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
PREFIX gct: <https://linked.data.gov.au/dataset/gnaf/code/geocodeType/>

SELECT ?a ?wkt
WHERE {
    ?a a addr:Address ;
        addr:hasGeocode [
            dcterms:type gct:PAP ;
            geo:asWKT ?wkt ;
        ] .

    FILTER (geof:sfWithin(?wkt, "POLYGON ((154 -27, 154 -28, 153 -28, 153 -27, 154 -27))"))
}

The results from this query are:

?a ?wkt

a:GAQLD161337673

"POINT(153.157220 -27.624450)"

a:GAQLD155231408

"POINT(153.157220 -27.624450)"

a:GAQLD161294216

"POINT(153.045546 -27.341745)"

Two of the results have the same geocode location. This is due to a:GAQLD155231408 being a primary address with a:GAQLD161337673 being a secondary and sharing a Property Access Point location (geocode).

Without the spatial bounding box filter, we would also get one more result:

?a ?wkt

a:GAQLD157959170

"POINT(151.95179638 -28.82625239)"

Removing the geocode type filter, we get all of the Addresses that have Geocodes, and the Geocodes' values, in the extended examples: there are 19.

So SPARQL queries can filter results on type and also using spatial relations, such as within a given area.

C.1.3 Selecting Addresses in relation to an object

SPARQL queries can select Addresses based on Address Component values which may either be literal values (numbers/strings) or complex objects.

To get all the example Addresses within the Queensland locality of Shorncliffe:

PREFIX addr: <https://w3id.org/profile/anz-address/>
PREFIX loc: <https://linked.data.gov.au/dataset/gnaf/locality/>

SELECT ?a ?val ?val_text
WHERE {
  ?a addr:hasAddressComponent/addr:hasValue loc:loc38f189794e03
}

This query finds two results (the oxford-place examples) since they indicate they have Shorncliffe as an Address Component of type isov1:locality by reference to the GNAF Locality PID https://linked.data.gov.au/dataset/gnaf/locality/loc38f189794e03.

To find all of the Addresses in Queensland we could use the PID of Queensland given by the Australian Statistical Geography Standard since that’s the object ID related to in this examples data

PREFIX addr: <https://w3id.org/profile/anz-address/>
PREFIX loc: <https://linked.data.gov.au/dataset/gnaf/locality/>

SELECT ?a ?val ?val_text
WHERE {
  ?a addr:hasAddressComponent/addr:hasValue <https://linked.data.gov.au/dataset/asgsed3/STE/3>
}

Note that the PID for Queensland is external to this model but resolves, online to the ASGS Queensland object:

C.2 Relational Database Demo

The 15 or so extended examples within the code repository (see above Annex for details) have been stored in an SQLite Database also within this code repository.

Note
To be fully functional, the SpatiaLite extension to SQLite need to be enabled so spatial functions may be performed. This extension is NOT enabled for this demonstration database to keep the geometry data human-readable (text) rather than implementing it as binary data types.

The database consists of 21 tables that together store:

  • the primary data of the examples

    • the Addresses in table addresses, Address Components in address_components etc.

  • the codelists/vocabularies listed in Supporting Vocabularies

    • as lookups

  • an IRI prefixes table

    • mapping short form IRIs to complete IRIs

    • as per Namespaces

These tables fully represent the content of the examples and the database schema used is therefore a complete relational implementation of this model.

To show equivalence to the RDF Database Demo, the three SPARQL queries shown there are reimplemented as SQLite SQL queries next.

Additionally, C.2.4 Converting relational to RDF data demonstrates how to convert some of the content from this relational implementation to RDF so it may be validated using the validators in Annex A: Validators.

C.2.1 Ordered Address Components

The following query yields identical results to that in C.1.1 Ordered Address Components:

SELECT *
FROM addresses_components
ORDER BY
  address_pid,
  CASE type
    WHEN 'isov1:buildingName' THEN 0
    WHEN 'isov1:propertyName' THEN 1
    WHEN 'isov1:traditionalPlaceName' THEN 2
    WHEN 'isov1:flatTypeCode' THEN 3
    WHEN 'isov1:flatNumber' THEN 4
    WHEN 'isov1:numberFirst' THEN 5
    WHEN 'isov1:streetLocality' THEN 6
    WHEN 'isov1:locality' THEN 7
    WHEN 'isov1:postcode' THEN 8
    WHEN 'isov1:administrativeArea' THEN 9
  END

C.2.2 Selecting addresses by geocode type and in an area

To make an SQL query equivalence to the sPARQL query in C.1.2 Selecting addresses by geocode type and in an area, an SQL join between the addresses and geocodes tables must be performed:

SELECT pid, geometry
FROM addresses
JOIN geocodes
ON addresses.pid = geocodes.address_pid
WHERE type = 'gt:PAP'
AND MBRWithin(
        GeomFromText('POLYGON ((154 -27, 154 -28, 153 -28, 153 -27, 154 -27))'),
        geometry
    );

Results from this query are the same as those in C.1.2 Selecting addresses by geocode type and in an area.

Note
For true operations, the function MBRWithin requires a GEOMETRY data field to operate on, not text as this example geometry field is. This example uses text so the values can be read. Removing the MBRWithin clause from the query above results in 4 results from the SQLite database, as per the reduces SPARQL query example above.

C.2.3 Selecting Addresses in relation to an object

The following SQL query performs equivalently to the first query in C.1.3 Selecting Addresses in relation to an object.

SELECT address_pid, has_value, has_value_text
FROM addresses_components
WHERE has_value = 'loc:loc38f189794e03'

Results for this query are the same as the equivalent SPARQL query.

Note
To match on a full IRI for 'loc:loc38f189794e03', which the equivalent SPARQL query above does with use of the prefix statement PREFIX loc: https://linked.data.gov.au/dataset/gnaf/locality/, the SQLite table pid_prefixes can be consulted to interpret 'loc:' in the query below.

C.2.4 Converting relational to RDF data

Since content according to this model can only be canonically represented in RDF, it is necessary that all other forms of content claiming conformance to this model show they can be converted to RDF for canonical data validation using the validators in Annex A: Validators.

The following SQL query obtains all the information necessary to formulate RDF for the valid example address http://example.com/oxford in the file extended-examples/oxford-place.ttl:

SELECT
    a.pid, a.is_address_for,
    ac.type, ac.has_value, ac.has_value_text,
    g.geometry, g.type,
    aa.address_pid
FROM addresses a
JOIN addresses_components ac
ON a.pid = ac.address_pid
JOIN geocodes g
ON a.pid = g.address_pid
JOIN address_aliases aa
ON a.pid = aa.alias_pid
WHERE a.pid = 'ex:oxford';

In the query above, a 4-table join is performed to obtain Address, Address Component, Address Geocode and Address Alias data.

A simple string templating function in a programming language such as Python may be used to convert those results into RDF or an RDF toolkit, such as Python’s RDFLib or Java’s Jena, may be used.

The file rdf_converter.py is a Python script that:

  • reads the Relational Database Demo file

  • utilises the pid_prefixes to map prefixed data to full IRIs

  • extracts all the elements of the http://example.com/oxford using the query above

  • adds all elements ton an RDF graph

  • prints the graph to text

The resultant graph is valid according to both of the validators files in Annex A: Validators, just as the original in the extended-examples folder is.

C.3: G-NAF for Queensland Demo

The entire contents of the Geocoded National Address File (G-NAF) for Queensland have been converted into this model’s relational form as per the SQLite implementation described above in C.2 Relational Database Demo.

This complete conversion demonstrates this model’s ability to represent the entire content of the G-NAF for Queensland but it is too large to include in this model’s code repository. It may be obtained on request from this model’s author.

Bibliography