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.
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. |
Major modelling principles present in this model are:
-
Resource / Compound Name split
-
Compound Name Component typing
-
Compound Names can contain other Compound Names
-
Providing templates for literal name assembly
These principles are explained in the following sub-sections.
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).
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.
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].
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.