A Semantic Web data model for compound names that may be assigned to resources.

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

1. Metadata

IRI

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

Preferred Label

Compound Naming Model

Definition

A Semantic Web data model for compound names that may be assigned to resources.

Date Created

2023-04-26

Date Modified

2023-05-31

Date Issued

2023-04-26

Creator

Nicholas J. Car

Publisher

Australian Government Linked Data Working Group

Provenance

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 however, recognising the generic nature of this modelling, it was presented to the AGLDWG to be supplied as a "background model" for general use.

Status

Ready for use

Version

:0.0.2

Code Repository

https://github.com/AGLDWG/compound-naming-model

License

Creative Commons Attribution 4.0 International (CC BY 4.0)

Copyright

© Australian Government Linked Data Working Group, 2023

Machine-readable form (RDF)

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

2. Preamble

2.1. Abstract

A Semantic Web data model for compound names may be assigned to resources.

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 this namespaces, used throughout this document, are listed below.

Prefix Namespace Description

:

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

Namespace for this model

ex

http://example.com/

Generic examples

geo

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

OGC GeoSPARQL 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

sdo

https://schema.org/

schema.org vocabulary

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

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 all use the key given in Figure 1.

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.

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

This document

Specification

The normative description of this model

Model in RDF

Schema

The technical, machine-readable, version of this model in [RDF].

Validator

Validation

The machine-readable validator file used to validate data claiming conformance to this model, as per the description of validation in Section Validation.

Directory of Examples

Examples

Examples, as presented in Examples in [RDF] code files.

3. Introduction

This model allows for the representation of compound names that can be assigned to be assigned to resources.

One example of a compound name is a geographical name - Moreton Island - and another is a street address:

72 Yundah Street
Shorncliffe
Queensland 4017
Australia

The first may be assigned to a mountain, the second a dwelling.

These compound names - and there are many other existing and potential forms - are made of parts and the parts are ordered and presented in some form, perhaps a contracted form, for different purposes. Parts may, in turn, be made of further parts.

The underlying logic of separating compound names from the things named is evident in many data standards, such as the ISO’s [ISO19160-1] Addressing - Part 1: Conceptual Model, which separates an Address from an Addressable Object.

3.1. Sources of Requirements

This model was initially built to allow Queensland Government to manage Addresses, geographical Names, Road Names and other forms of name for geospatial objects in a similar manner with naming data stored outside spatial data systems. Within this, several specific modelling principles were established, such as Compound Name component typing.

The main principles are listed in the following section. Additionally, the validators for this model check for conformance of data to these principles, see the section Validation.

Note
 While Queensland Government uses this model to name geospatial objects, any object - a generic resource - may be named using it: there is nothing inherently geospatial about compound naming.

3.2. Major Modelling Principles

Major modelling principles present in this model are:

  1. Resource / Compound Name split

  2. Compound Name Component typing

  3. Compound Names can contain other Compound Names

  4. Providing templates for literal name assembly

These principles are explained in the following sub-sections.

3.2.1. Resource / Compound Name split

Names may be complex things - made of multiple parts that are rendered in different ways for different purposes, in multiple languages etc. - and the things names may be complex too - be spatial with multiple geometries, detailed properties etc. For this reason, we separate the representation of compound names from the resources named, as per Figure 1.

The implication of this is that we can handle Resource instances and CompoundName instances for them separately both within conceptual & logical models, and also within implementations, physical models. This offers great flexibility in handling resources and compound names, and we can do things like implement independent lifecycles for them and use dedicated tools for certain kinds of resources (e.g. geospatial features).

3.2.2. Compound Name Component typing

The different parts of a CompoundName will have different types, for example, Moreton Island mentioned above has a basic name part - "Moreton" and a typing part "Island".

Since we intend this model to be used in different scenarios - geographical object naming, indigenous place naming, addressing and more - we allow the parts of a CompoundName object to have sub-types assigned to them which may be selected from a domain-specific types vocabulary.

For geographical name Moreton Island again, we may type the "Moreton" part as a geographical name and the "Island" part as a geographical object category.

3.2.3. Compound Names can contain other Compound Names

Where Resource instances have names that have relations to other Resource instances with names, CompoundName instances might need to be built by compounding other CompoundName instances. For example, the Address

72 Yundah Street
Shorncliffe
Queensland 4017
Australia

includes a road number - "1" - and a road name - "Yundah Street" - as well as a locality name - "Shorncliffe" and other things. "Yundah Street" could easily be a CompoundName for a Road object and "Shorncliffe" a (simple) compound name for a Locality object. If names are provisioned for that Road and Locality object, then the Address compound name may be created by retrieving their names and then placing them into a template like this:

{Road Number} {Road Name}
{Locality}
{State} {Postcode}
{Country}

See the next section for templating.

To enable this compounding logic, this model specifies that users of this model must provide a function that accepts a CompoundName object reference (identifier) and a template or template reference or that uses a default template and produces a literal version of it for every class of CompoundName that they implement. This is defined in the section Functions.

3.2.4. Providing templates for literal name assembly

In most cases of name use, we need to have the parts of the CompoundNameComponent presented in a particular order. In Australia, this Address makes sense:

72 Yundah Street
Shorncliffe
Queensland 4017
Australia

This does not:

4017
Street Queensland
Australia 72
Shorncliffe

We may also have more than one sensible order for a CompoundName, for example, we may wish to render the Address example above on a single line:

72 Yundah Street, Shorncliffe, Queensland 4017 Australia

We may also wish to contract terms - Street - to "St" and to add other punctuation - Island → "Is.".

For these reasons, users of this model must implement at least one template for CompoundName literal rendering.

Without specific context, this model cannot implement name templating here.

4. Model

This model is composed of Web Ontology Language (OWL) [OWL] Classes and Properties. Some of them are defined in this model and others are from other, well-known, ontologies and reused here. Each element indicates where it is defined using the Is Defined By predicate.

4.1. Classes

4.1.1. Compound Name

Property Value

IRI

: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

This model

Expected Properties

is name for, has part

Example

 
# An example Compound Name that is an Address,
# constructed in the manner of Australian street addresses
# and typically rendered for letter sending as:
#
# 72 Yundah Street
# Shorncliffe, QLD, 4017
# Australia
#
PREFIX : <https://linked.data.gov.au/def/fl/>
PREFIX ex: <http://example.com/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX sdo: <https://schema.org/>

ex:72-yundah
    a :CompoundName ;
    sdo:hasPart [
        sdo:additionalType ex:streetNumber ;
        rdf:value 72 ;
    ] ,
    [
        sdo:additionalType ex:streetName ;
        rdf:value "Yundah" ;
    ] ,
    [
        sdo:additionalType ex:streetType ;
        rdf:value ex:Street ;
    ] ,
    [
        sdo:additionalType ex:locality ;
        rdf:value ex:Shorncliffe ;
    ] ,
    [
        sdo:additionalType ex:state ;
        rdf:value ex:Queensland ;
    ] ,
    [
        sdo:additionalType ex:postCode ;
        rdf:value 4017 ;
    ] ,
    [
        sdo:additionalType ex:country ;
        rdf:value ex:Australia ;
    ] ;
.

# An example Compound Name that is a Geographical Name,
# for an island off the coast of Brisbane, Australia
# that may be rendered as either Moreton Island or perhaps
# Moreton Is.
#
ex:moreton
    a :CompoundName ;
    sdo:hasPart [
        sdo:additionalType ex:geographicalName ;
        rdf:value "Moreton" ;
    ] ,
    [
        sdo:additionalType ex:geographicalName ;
        rdf:value ex:Island ;
    ] ;
.

4.1.2. Resource

Property Value

IRI

rdfs:Resource

Preferred Label

Resource

Definition

The class resource, everything

Is Defined By

RDF 1.2 Schema

Scope Note

This class is used to represent both the things to which CompoundNames can be assigned and also the range value of the property rdf:value. It is not expected to be used directly but instead specialised types of Resource are expected

Example

See the non-literal values for rdf:value in the CompoundName example

4.1.3. Literal

Property Value

IRI

rdfs:Literal

Preferred Label

Literal

Definition

The class of literal values, eg. textual strings and integer

Is Defined By

RDF 1.2 Schema

Scope Note

This class is used to represent the range value of the property :asLiteral. It is not expected to be used directly but instead specialised types of Literal are expected

Example

See the literals values of '72' and 'Yundah' in the CompoundName example

4.1.4. Concept

Property Value

IRI

skos:Concept

Preferred Label

Concept

Definition

An idea or notion; a unit of thought

Is Defined By

SKOS Reference

Expected Properties

Standard SKOS properties for Concepts

Scope Note

This class is the type of the expected values for the property sdo:additionalType when used within this model. Concepts are typically controlled terms within ConceptSchemes. Literal representations of Concepts should easily be obtainable

Example

 
# See the example for CompoundName and add the following
#
PREFIX ex: <http://example.com/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

ex:Island
    a skos:Concept ;
    skos:inScheme ex:someConceptScheme ;
    skos:prefLabel "Island" ;
    skos:altLabel "Is." ;
.

4.2. Properties

4.2.1. is name for

Property Value

IRI

:isNameFor

Preferred Label

is name for

Definition

Inverse of sdo:name

Is Defined By

This Model

Inverse Of

name

Example

 
# Moreton Island is the Compound Name
# for a spatial object off the coast of Brisbane, Australia
#
PREFIX : <https://linked.data.gov.au/def/cn/>
PREFIX ex: <http://example.com/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX sdo: <https://schema.org/>

ex:moreton
    a :CompoundName ;
    :isNameFor ex:feature-x ;
.

ex:feature-x
    a geo:Feature ;
    sdo:name ex:moreton ;
.

4.2.2. name

Property Value

IRI

sdo:name

Preferred Label

name

Definition

The name of the item

Is Defined By

schema.org

Scope Note

In this model, name is used to indicate both a literal form of a resource`s name or a CompoundName object

Example

See example for is name for

4.2.3. has part

Property Value

IRI

sdo:hasPart

Preferred Label

has part

Definition

Indicates a Resource that is part of this item

Is Defined By

schema.org

Example

See the example for Compound Name

4.2.4. value

Property Value

IRI

rdf:value

Preferred Label

value

Definition

Idiomatic property used for structured values

Is Defined By

RDF 1.2 Schema

Example

See the example for Compound Name

Scope Note

Use this property to indicate the value of a CompoundName, whether it’s a literal or a complex object

4.2.5. additionalType

Property Value

IRI

sdo:additionalType

Preferred Label

additional type

Definition

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

Is Defined By

schema.org

Example

See the example for Compound Name

Scope Note

Use this property to indicate the specialised type of a part of a CompoundName

5. Functions

Use of this model in which CompoundName instances contain other CompoundName instances as parts requires the implementation of a function to create a literal form of those contained CompoundName instances. This is described further in the section Compound Names can contain other Compound Names.

This function MUST be called getLiteralName and must have the following function signature:

function getLiteralName(CompoundName, template (Optional)) -> Literal

In words:

  • the function getLiteralName must accept a Compound Name Object or object reference and optionally a template or template reference as input parameters

    • if no template is supplied, a default template for the given class of CompoundName must be used.

  • the function returns a literal representation of the CompoundName object

5.1. Function Example

The ex:moreton is an instance of a GeographicalName which is a specialised form of CompoundName. It consists of the parts shown in the example for Compound Name.

The function getLiteralName is used as follows:

getLiteralName(ex:moreton)

No template is specified so the system uses the default template for the class GeographicalName which is simply:

{GeographicalFeatureName} {GeographicalFeatureTypeName}

which, in this case, returns:

Moreton Island

The function is then used as follows:

getLiteralName(ex:moreton, contractedTemplate)

where the template contractedTemplate shortens GeographicalFeatureTypeName, in this case "Island" → "Is." thus the function returns:

Moreton Is.

6. Validation

Still to be implemented.

7. Examples

These examples are figures based on the data for the example given for the Compound Name class description.

7.1. Address

Example1
Figure 2. Example subclasses of Resource and corresponding Compound Names

7.2. Geographical Name

Example2
Figure 3. Example subclasses of Resource and corresponding Compound Names

Bibliography

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

  • [FLM] The State of Queensland (Department of Resources). Compound Naming Model. Semantic Web data model (2023). https://linked.data.gov.au/def/flm

  • [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

  • [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

  • [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/

  • [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/