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

act

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

This model’s AddressComponentType vocabulary namespace

actiso

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

[ISO19160-1]'s AddressComponentType vocabulary namespace

als

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

This model’s AddressLifecycleStageType vocabulary namespace

alsiso

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

[ISO19160-1]'s AddressLifecycleStageType vocabulary namespace

ast

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

This model’s AddressStatusType vocabulary namespace

astiso

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

[ISO19160-1]'s AddressStatusType 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 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 modelling of 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. Address / Spatial object principle

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] with some further integration of the AddressableObject concpet with general-purpose spatial models, in particular GeoSPARQL [GEO].

The following figure overviews this model’s address / spatial object split.

address spatial
Figure 2. Address / spatial object relation overview

In the figure above, the spatial object that is the target of an address, an addressable object, is a subclass of (special type of) the GeoSPARQL model’s Feature class, which is really any geospatial feature. Spatial relations between addresses and other objects and spatial projects of objects (their geometries) are then modelled as spatial concerns within GeoSPARQL’s general spatial modelling.

The only exception to this are addresses' geocodes which are modeled as direct properties of (related geometries of) addresses. This is because while an address might be for a spatial object with a certain geometry, the geocode for the address might not be directly inherited from that spatial object but might be manually or otherwise defined.

For example, an emergency services access address for a hospital might need a more precise location than the footprint of the hospital property with might be large. In this case, an address with the emergency access role may be defined for the hospital with a precise point geocode which will likely be on or close to the hospital building’s boundary.

3.2. 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: Validators & Validator

Validation

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

Annex B: Extended Examples & Extended 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 3. An informal Model Overview diagram showing the major elements of this model
upper classes
Figure 4. 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 5. 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 uses many vocabularies to give specific values to classification properties for Address, AddressComponent and to qualify relationships within the model. This section lists those vocabularies and summarises their content but not their full content which is instead linked to.

Four vocabularies expected for use with this model are defined here, within the model. Others are defined elsewhere, mainly ICSM vocabularies derived from AS4189 or the G-NAF.

Those defined here are:

Three of these vocabularies are derived from vocabularies (codelists) within [ISO19160-1] but all are extended for use here. The remaining vocabulary - Address Role Types - is derived from the various elements of [ISO19160-1] but not directly from one vocabulary.

Those defined as ICSM vocabularies:

  • Address Types

  • Address Alias Types

  • Address Role Types

  • Flat Types

  • Geocode Types

  • Level Types

  • Street Suffix Types

  • Street Types

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. Address Component Types

This vocabulary is an extended version of [ISO19160-1]'s AddressComponentType vocabulary. The original 8 concepts from the standard are included however only one of them - postcode - is suggested for use within this model. An additional 19 concepts are taken from address elements in the G-NAF, such as numberFirstSuffix. A further 4 concepts have also been added during the design of this model to cater for newly understood future ANZ addressing needs, such as placeName and indigenousPlaceName.

IRI Status Usage directive

actiso:addressedObjectIdentifier

original

Do not use: handled by Address/AddressableObject relation

actiso:administrativeAreaName

original

Do not use: use object reference types

actiso:countryCode

original

Do not use

actiso:countryName

original

Use

actiso:localityName

original

No not use: use act:locality

actiso:postOfficeName

original

Do not use

actiso:postcode

original

Use

actiso:thoroughfareName

original

Do not use, use act:streetLocality

act:buildingName

addition (G-NAF)

Use

act:lotNumberPrefix

addition (G-NAF)

Use

act:lotNumber

addition (G-NAF)

Use

act:lotNumberSuffix

addition (G-NAF)

Use

act:flatTypeCode

addition (G-NAF)

Use

act:flatNumberPrefix

addition (G-NAF)

Use

act:flatNumber

addition (G-NAF)

Use

act:flatNumberSuffix

addition (G-NAF)

Use

act:levelTypeCode

addition (G-NAF)

Use

act:levelNumberPrefix

addition (G-NAF)

Use

act:levelNumber

addition (G-NAF)

Use

act:levelNumberSuffix

addition (G-NAF)

Use

act:numberFirstPrefix

addition (G-NAF)

Use

act:numberFirst

addition (G-NAF)

Use

act:numberFirstSuffix

addition (G-NAF)

Use

act:numberLastPrefix

addition (G-NAF)

Use

act:numberLast

addition (G-NAF)

Use

act:numberLastSuffix

addition (G-NAF)

Use

act:streetLocality

addition (G-NAF)

Use

act:locality

addition (G-NAF)

Use

act:stateOrTerritory

addition

Use

act:propertyName

addition (this model)

Use

act:placeName

addition (this model)

Use

act:indigenousPlaceName

addition (this model)

Use

5.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

IRI Status Usage directive

alsiso:current

original

Use unless superseded

alsiso:proposed

original

Use unless superseded

alsiso:rejected

original

Use unless superseded

alsiso:reserved

original

Use unless superseded

alsiso:retired

original

Use unless superseded

alsiso:unknown

original

Use unless superseded

5.3. Address Role Types

This vocabulary is inspired by [ISO19160-1]'s AddressPosition and AddressPositionType classes and the often repeated need in ANZ to assign purposes to Addresses. All elements are original in this model.

IRI Status Definition

Usage directive

role:deliveries

deliveries

An address to use for deliveries

Use

role:emergencyAccess

emergency access

An address to use for emergency services' access

Use

role:serviceConnectionPoint

service connection point

An address at which utility services are connected

Use

role:siteOffice

site office

5.4. Address Status Types

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

IRI Status Usage directive

astiso:official

original

Use unless superseded

astiso:unknown

original

Use unless superseded

astiso:unofficial

original

Use unless superseded

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 actiso: <http://def.isotc211.org/iso19160/-1/2015/Address/code/AddressComponentType/>

SELECT ?a ?ac_type ?val ?val_text
WHERE {
    VALUES (?ac_type ?ac_order) {
        (actiso:buildingName 1)
        (actiso:propertyName 2)
        (actiso:indigenousPlaceName 3)
        (actiso:flatTypeCode 4)
        (actiso:flatNumber 5)
        (actiso:numberFirst 6)
        (actiso:streetLocality 7)
        (actiso:locality 8)
        (actiso:postcode 9)
        (actiso: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

actiso:flatNumber

"2"^^xsd:integer

"2"

a:GAQLD161268186

actiso:numberFirst

"18"^^xsd:integer

"18"

a:GAQLD161268186

actiso:streetLocality

sl:QLD140492

"Oxford Place"

a:GAQLD161268186

actiso: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 actiso: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 'actiso:buildingName' THEN 0
    WHEN 'actiso:propertyName' THEN 1
    WHEN 'actiso:indigenousPlaceName' THEN 2
    WHEN 'actiso:flatTypeCode' THEN 3
    WHEN 'actiso:flatNumber' THEN 4
    WHEN 'actiso:numberFirst' THEN 5
    WHEN 'actiso:streetLocality' THEN 6
    WHEN 'actiso:locality' THEN 7
    WHEN 'actiso:postcode' THEN 8
    WHEN 'actiso: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