A Semantic Web data model used for roads information

Overview
Figure 1. An overview of this model

1. Metadata

IRI

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

Preferred Label

Roads Model

Definition

A Semantic Web data model of roads information. It caters specifically for Australian & New Zealand’s road labelling (naming) needs.

Created

2023-04-11

Modified

2023-06-12

Issued

0000-00-00 - not formally issued yet

Creator

Nicholas J. Car

Publisher

Queensland Spatial Information

History Note

This model was made for Queensland Spatial Information, a unit of the Queensland Department of Resources, to assist with their future address and roads database design. It is a Component Model of their 'QSI Supermodel' which includes models for Address, Place Name and Cadastral information which are all designed to work together, however they may all be used independently too.

Status

Beta version

Version

:0.0.1

Code Repository

https://github.com/Spatial-Information-QLD/roads-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/roads.ttl

2. Preamble

2.1. Abstract

A Semantic Web data model of roads information. It caters specifically for Australian & New Zealand’s road naming needs.

Note
 This model was made for Queensland Spatial Information, a unit of the Queensland Department of Resources, to assist with their future address and roads database design. It is a Component Model of their 'QSI Supermodel' which includes models for Address, Place Name and Cadastral information which are all designed to work together, however they may all be used independently too.

2.2. Namespaces

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

Prefix Namespace Description

:

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

This model

rnpt

https://linked.data.gov.au/def/road-name-part-types/

Supporting vocabulary - Road Name Part Types

rt

https://linked.data.gov.au/def/road-types/

Supporting vocabulary - Road Types

cn

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

Compound Name Model

dcterms

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

Dublin Core Terms

ex

http://example.com/

Generic examples

geo

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

OGC GeoSPARQL model

lm

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

Lifecycle Model

owl

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

Web Ontology Language ontology

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

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

3. Introduction

This model facilitates applying Road Name objects, with potentially many subcomponents, to the geospatial representation of roads - Road Objects. This style of feature name / geospatial feature modelling is informed inherited from the Compound Naming Model that this model extends.

Note
 This model does not attempt to assist with detail geospatial aspects of road modelling: it only provides an association between naming components and geospatial representations of the road established using other models and with categorisation of road objects. This model also does not link road objects to other, related, objects, such as Localities. Such linking should be represented with Feature / Feature topological relations, such as those within GeoSPARQL GEO.

Data made according to this model, when stored in one of the RDF serialization formats such as TTL, is directly validatable according to this model through use of validators that are supplied, see Section Validation.

3.1. Sources of Requirements

This model was initially built to allow Queensland Government to manage roads naming information in a manner similar to how they manage Address & Geographic Name information: as a collection of Feature Names for Features which have Geometries. This introduces requirements to both facilitate complex naming and align with Address etc. modelling.

To ensure that this model implements that Feature Name / Feature / Geometry pattern, it is a profile of the Compound Naming Model which captures the pattern in generic form and is also profiled by Queensland Government’s Address & Geographic Names Models. Figure Roads Object spatial modelling overviews this. This introduces the requirement for all Roads Model information to conform to the Compound Names Model - the necessary requirement for profiling.

By profiling that model, this model also remains interoperable with detailed spatial object modelling, for example of the sort implemented in the Cadastre Model.

Detailed requirements for this model all stem from these top-level requirements. The individual requirements are listed in the Requirements section.

3.2. Major Modelling Principles

Major modelling principles present in this model are:

  1. Feature / Feature Naming differentiation

  2. Feature / Geometry differentiation

  3. Profile Views

These principles are explained in the following sub-sections and the first two reference the following figure.

Spatiality
Figure 3. Roads Object spatial modelling

3.2.1. Feature / Feature Naming differentiation

This model details the elements of a road name but not details of the spatial objects that addresses are assigned to - the geospatial road objects. The general conceptual split of name/spatial object follows the Address/AddressableObject split in ISO19160-1 ISO19160-1. Addresses there are seen as a form of complex, multi-part, label - Feature Name - for a spatial Feature and Road Names here are considered a simple case of that.

This allows for the representation, and ultimately the management, of names - text, numbers, identifiers, references - separately to the management of spatial objects and their properties, such as the physical presentation of a Road.

This Feature / Feature Naming separation applies to Geographic Names, Roads and Administrative Areas as well as Addresses and this expression of Feature / Feature Naming separation for addressing is a formal profile of the more general Compound Naming Model CNM. There are other profiles for those other domains. The CNM, this model and the other CNM profiles are all pat of Queensland Spatial Information’s Supermodel which is an enterprise data model for multi-model data integration.

3.2.2. Feature / Geometry differentiation

(Geo)spatial objects referenced by this model’s naming objects (Road Names) are not geometries but conceptual spatial objects that have as an expression of their spatial projection one or more geometries. See Figure Roads Object spatial modelling. This conceptual object - Feature - and spatial expression - 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 distinction 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. This would allow Road Objects to have spatiallity represented with road centrelines, area polygons from cadastre etc., all at the same time, by linking those different spatial representations - the Geometries - to the single conceptual entity - the Feature.

3.3. Profile Views

Road Names have multiple roles: they indicate places with names (or Features with Names), they are things to be managed by data holders, and they have statuses, lifecycles and so on. Sometimes we are only interested in one of these aspects of a Road Name or one profile and not the total information held. We may also be interested only in a reduced set of properties of a Road Name even when others within that role are present, e.g. the current status, not all the statues an Address has ever had. Finally, different implementers of this model may want to implement different jurisdictional profiles of the model that, for example, mandate certain information be stored for Road Names, that may be meaningless outside that jurisdiction.

All of these sorts of profiles of Road Names are handled in a similar way in this model: they are declared Profiles of the model that may implement additional rules and/or requirements on data, however they must always conform to the main Roads Model itself.

Profile modelling is given in PROF and requesting profiles from data conforming to a model is given in CONNEGP.

3.4. 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 used by this model

Requirements Section

Guidance

The Requirements addressed by this model

Validation Section & SHACL Validator

Validation

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

Templating Section

Guidance

The template logic used for Basic and Short Form templates

Examples Section & Extended example data files

Example

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

Code Repository

Code Repository

The online, version control, repository containing all the resources of this model

4. Model

This model is composed of Web Ontology Language (OWL) OWL Classes and Properties. While some 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 and together. This is in contrast to Unified Modelling Language (UML) Class Diagrams which treat Properties as sub-parts of particular classes.

This model defines only two 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.

4.1. Classes

4.1.1. Road Name

Property Value

IRI

:RoadName

Preferred Label

Road Name

Definition

The Road Name class represents structured information that allows unambiguous determination of a Road Object for the purposes of identification and location

Is Defined By

This model

Sub-class Of

cn:CompoundName

History Note

Specialised from CNM's Compound Name class

Expected Properties

is name for, value, additionalType, hasPart, has lifecycle stage

Example

 
# Yundah Street South
ex:road-name-1
  a :RoadName ;
  cn:isNameFor <some-external-object> ;
  sdo:hasPart
    [
      rdf:value "Yundah" ;
      sdo:additionalType rnpt:RoadGivenName ;
    ] ,
    [
      rdf:value st:Street ;
      sdo:additionalType rnpt:RoadType ;
    ] ,
    [
      rdf:valueText "South" ;
      sdo:additionalType rnpt:RoadSuffix ;
    ] ;
.

4.1.2. Road Object

Property Value

IRI

:RoadObject

Preferred Label

Road Object

Definition

A geospatial object that is unambiguously identified by a Road Name.

Examples of types of RoadObjects are a sequences of cadastral parcels of type road.

Is Defined By

This model

Sub-class Of

geo:Feature

History Note

Specialised from GEO's Feature class, as used in CNM

Scope note

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

Expected Properties

hasGeometry, additionalType, theme, hasPart,

Example

 
# ex:parcel-aggregate-x is inferred to be a Road Object
# due to the property cn:isNameFor indicating it
# on a Road Name instance

ex:road-name-1
  a :RoadName ;
  cn:isNameFor ex:parcel-aggregate-x ;
  ...
.

4.1.3. 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 Road Name class. This class is also used for instances of Road Name parts

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

Lifecycle Model

Scope Note

Used to indicate the lifecycle stage of any Roads 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.5. 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 Road Object class

4.1.6. 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.7. 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.8. 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. 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

 
# A road with a name
PREFIX ex: <http://example.com/>

ex:road-name-x
    a :RoadName ;
    cn:isNameFor ex:road-object-y ;
.

ex:road-object-y
    a :RoadObject , geo:Feature ;
    sdo:name ex:road-name-x ;
.

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

 
# A Road Name with two Lifecycle Stages indicated:
# one current and one past
ex:road-name-x
  a :RoadName ;
  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.3. 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

4.2.4. 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 Road Name and Road Object instances

4.2.5. 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 Road Name or of a Road Object

4.2.6. 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 a Road Object

4.2.7. theme

Property Value

IRI

dcat:theme

Preferred Label

theme

Definition

A main category of the resource. A resource can have multiple themes

Is Defined By

DCAT

Range

Concept

Scope Note

Used to indicate Road Object categorisations

5. Supporting Vocabularies

This model depends on several vocabularies to give specific values for certain theming - general classification - and sub-typing properties.

The vocabularies are all independently-published and governed Knowledge Graph artifacts and do not record any relation to this model in their own data.

The vocabularies' details are given in the table below.

Persistent IRI Name Description Model property

Road Names

https://linked.data.gov.au/def/road-name-part-types

Road Name Part Types

This vocabulary describes values of name part types used in road naming

sdo:additionalType for a Road Name’s Compound Name part

https://linked.data.gov.au/def/road-types

Road Types

This vocabulary describes road types. A road type is used as part of a road name and distinguishes the type of road. The road types that do not meet AS/NZS 4819:2011 exist to enable inclusion of roads named prior to the creation of AS/NZS 4819:2011. These types should not be used for any new road designations

rdf:value for a Road Name’s Compound Name part of sdo:additionalType Road Type

https://linked.data.gov.au/def/road-suffixes

Road Suffixes

This vocabulary describes values of suffixes used in road naming

rdf:value for a Road Name’s Compound Name part of sdo:additionalType Road Suffix

Road Objects

https://linked.data.gov.au/def/road-classifications

Road Classifications

This vocabulary describes hierarchy classification types for roads

sdo:additionalType for a Road Object

https://linked.data.gov.au/def/road-operational-statuses

Road Operational Statuses

This vocabulary describes the operational status for roads

dcat:theme for a Road Object

https://linked.data.gov.au/def/road-sub-classes

Road Sub-Classes

This vocabulary describes sub classifications of roads

dcat:theme for a Road Object

https://linked.data.gov.au/def/road-surfaces

Road Surfaces

This vocabulary describes surfaces of roads

dcat:theme for a Road Object

6. Requirements

Here are the itemised Requirements referenced in the Sources of Requirements subsection of the Introduction and note for them on how this model satisfies them.

6.1. Requirements List

ID Name Description

Req01

MUST align with Address modelling

Profiles the Compound Naming Model CNM and the Lifecycle Model LM which the QSI Address Model also profiles

Req02

MUST implement the Feature Name / Feature pattern

Implements Road Name & Road Object to specialise the pattern for roads

Req03

MUST be interoperable with detailed spatial object modelling, for example of the sort implemented in the Cadastre Model

Implements Road Object as a GeoSPARQL Feature to which any GeoSPARQL spatial modelling can be applied

7. Validation

This section will be completed when Business Rules for Road Names are determined - etc. June, 2023

8. Templating

To present - on screen or in print form - the consolidated name for a Road Name, the parts need to be assembled in a particular order and perhaps processes to make contractions etc. The logic for this is not contained in the Classes or Properties of the model but in this Templating section.

Users of this model are free to implement additional templates and template logic to suit their needs.

8.1. Basic Template

This template assembles the parts of a Road Name’s in the most basic manner, and is expected to be the most commonly used template.

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

space = " "
extended_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" | " " | "-" ;
prefix = extended_letters
prefix_spaced = prefix, space
name = extended_letters
type = extended_letters
type_spaced = space, type
suffix = extended_letters
suffix_spaced = space, suffix

road_name = [prefix_spaced], name, [type_spaced], [suffix_spaced]

Consider a Road Name with the following parts:

  • Road Given Name, value text "Yundah"

  • Road Type, value text "Street"

  • Road Suffix, value text "South"

The template would result in this:

space = " "
name = "Yundah"
type = "Street"
type_spaced = " Street"
suffix = "South"
suffix_spaced = " South"

road_name = "Yundah Street South"

8.2. Short Form Template

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

This template uses the same layout logic as the Basic Template but makes certain contractions:

  • Street Type

    • Street → St

    • Road → Rd

    • Crescent → Crs

Etc., as per address regulations such as AS 4590.

  • Street Suffix

    • North → Nth

    • South → Sth

    • East → Est

    • West → Wst

Consider a Road Name with the following parts:

  • Road Given Name, value text "Yundah"

  • Road Type, value text "Street"

  • Road Suffix, value text "South"

This template’s result for these values will be calculated as per the Basic Template example with the same input values but with the contractions from the lists above applied result in:

Yundah St Sth

9. Examples

This model contains examples per Class and Property in the Model section as well as for each template within in the Templating section. Additionally, the following drawn examples are provided to illustrate modelling intentions.

9.1. Modelling Scenarios

EG Naming
Figure 4. Roads Naming example
EG Classifications
Figure 5. Roads Classification examples
EG Parts
Figure 6. Roads Parts examples

9.2. Code

The following code is the aggregate of the per-Class and Property examples.

# a geospatial Road Object instance
ex:road-x
    a ex:Road ;
.

# Yundah Street South with Feature Name and Lifecycle Stages indicated
ex:road-name-1
  a roads:RoadName ;
  cn:isNameFor ex:road-x ;
  sdo:hasPart
    [
      rdf:value "Yundah" ;
      sdo:additionalType rct:RoadName ;
    ] ,
    [
      rdf:value st:Street ;
      sdo:additionalType rct:RoadType ;
    ] ,
    [
      rdf:value "South" ;
      sdo:additionalType rct:RoadSuffix ;
    ] ;
  roads: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 ls:proposed ;
  ] ,
  [
    # this Stage is still in effect - no hasEnd given
    time:hasTime [
      time:hasBeginning [ time:inXSDDate "1982-05-11"^^xsd:date ] ;
    ] ;
    dcterms:type ls:current ;
  ] ;
.

The example above prints out as "Yundah Street South" using the Basic Template provided in the Templating section and "Yundah St Sth" using that section’s Short Form Template.

Bibliography

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/

DCAT

World Wide Web Consortium, Data Catalog Vocabulary (DCAT) - Version 2, W3C Recommendation 04 February 2020, https://www.w3.org/TR/vocab-dcat-2/

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

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)

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/

SDO

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

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/