Merge pull request #1 from icsm-au/voc-update

Voc update

00-master.adoc

@@ -24,7 +24,7 @@ include::03-introduction.adoc[]
 
 include::04-model.adoc[]
 
-include::05-supporting-vocabularies.adoc[]
+include::05-vocabularies.adoc[]
 
 :sectnums!:
 

01-metadata.adoc

@@ -2,15 +2,15 @@
 
 [width=75%, frame=none, grid=none, cols="1,5"]
 |===
-|**IRI** | `https://linked.data.gov.au/def/addr`
-|**Preferred Label** | Address Model
-|**Definition** | The national for address information for Australian & New Zealand, realised in Semantic Web form
-|**Created** | 2021-12-16
-|**Modified** | 2024-07-10
-|**Issued** | 2023-06-30
-|**Creator** | https://orcid.org/0000-0002-8742-7730[Nicholas J. Car]
-|**Publisher** | https://linked.data.gov.au/org/icsm[Intergovernmental Committee  on Surveying & Mapping (ICSM)]
-|**Provenance** | This model is https://www.anzlic.gov.au[ANZLIC]'s https://icsm.gov.au[Intergovernmental Committee  on Surveying & Mapping (ICSM)]'s models for addressing information in Australian & New Zealand.
+|*IRI* | `https://linked.data.gov.au/def/addr`
+|*Preferred Label* | Address Model
+|*Definition* | The national for address information for Australian & New Zealand, realised in Semantic Web form
+|*Created* | 2021-12-16
+|*Modified* | 2024-09-25
+|*Issued* | 2023-06-30
+|*Creator* | https://orcid.org/0000-0002-8742-7730[Nicholas J. Car]
+|*Publisher* | https://linked.data.gov.au/org/icsm[Intergovernmental Committee  on Surveying & Mapping (ICSM)]
+|*Provenance* | This model is https://www.anzlic.gov.au[ANZLIC]'s https://icsm.gov.au[Intergovernmental Committee  on Surveying & Mapping (ICSM)]'s models for addressing information in Australian & New Zealand.
 
 It was originally developed between 2021 and 2023 for Queensland Spatial Information, a unit of the Queensland Department of Resources, to assist with their future address database design, and presented to ICSM for national adoption in early 2024.
 
@@ -19,10 +19,13 @@ It is informed by the ICSM's Addressing 2035: Addressing Reform and Innovation f
 This model is also informed by both the relational database model used for the https://data.gov.au/data/dataset/geocoded-national-address-file-g-naf[G-NAF], Australia's Geocoded National Address File, and work by https://www.csiro.au[CSIRO] in 2018 to characterise the GNAF in Semantic Web form, the ontology for which is online at https://linked.data.gov.au/def/gnaf, as well as the https://www.iso.org[ISO]'s https://www.iso.org/standard/61710.html[ISO19160-1 Addressing Part 1: Conceptual model].
 
 In 2023, several parts of this model covering general modelling and spatial modelling issues, such as lifecycle representation, spatiality itself & compound naming, were extracted out into a series of mini-models that are also used by other candidate ICSM models for Place (Geographic) Names, Roads, Administrative Areas. Also, alignment to the ICSM's national https://linked.data.gov.au/def/csdm[Cadastral Survey Data Model (CSDM)] was made and, as a result, this model is both much reduced in complexity, a re-users of fundamental background models used by other, related, models and aligned with the only other ICSM national Semantic Web model.
-|**Status** | First stable version
-|**Version** | `addr:1.0.1`
-|**Code Repository** | https://github.com/Spatial-Information-QLD/address-model
-|**License** | https://creativecommons.org/licenses/by/4.0/[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/addr.ttl
+|*Status* | First stable version
+|*Version* |
+*1.0.2*: 2024-09 Support Vocabularies section updated to use ICSM vocabs +
+*1.0.1*: 2024-09 Geocode move to subclass of Geometry +
+*1.0.0*: 2024-06 As approved by ICSM for national use +
+|*Code Repository* | https://github.com/Spatial-Information-QLD/address-model
+|*License* | https://creativecommons.org/licenses/by/4.0/[Creative Commons Attribution 4.0 International (CC BY 4.0)]
+|*Copyright* | © The State of Queensland (Department of Resources) 2020-2023, Intergovernmental Committee on Surveying & Mapping, 2024
+|*Machine-readable form (RDF)* | https://linked.data.gov.au/def/addr.ttl
 |===

03-introduction.adoc

@@ -71,7 +71,7 @@ Some elements of addresses must be subclassified by, or in some other way associ
 
 Where such vocabularies are used, they are not directly published _within_ this model but externally and this model is expected to be used with them. In this way, vocabularies may be extended without extending this model and different users may implement their own vocabularies to suite their business needs, for example, perhaps not all model users allow all address part types Queensland does, such as _water feature number_ so, they should use this model with a vocabulary that excludes that term.
 
-See the <<Supporting Vocabularies>> section for mode information.
+See the <<Vocabularies>> section for mode information.
 
 
 ==== Feature / Feature Naming differentiation
@@ -96,11 +96,11 @@ While this model doesn't model spatial aspects of the object to which addresses
 
 ==== Geocodes
 
-Geocodes are spatial objects - Features - with point geometries that addresses may be associated with so that they can be used by mapping applications to locate the address, or part of an addressable object, on a map or on the earth.
+Geocodes are spatial objects - Geometries - with point coordinates that addresses may be associated with so that they can be used by mapping applications to locate the address, or part of an addressable object, on a map or on the earth. Geocodes always have both their position - a point location - and a role - what they mean - in relation to the Address they are associated with.
 
-Geocodes may be only indirectly related to an Addressable Object: while they may be calculated from them, for example they could be the centroid of a lot, they may also not be, for example they could be a GPS-marked point indicating a property entrance point that is on or close to the Addressable Object but has been determined independently of its details.
+Geocodes may be only indirectly related to an Addressable Object: while they may be calculated from them by being their centroid, they may also be created independently, for example they could be a GPS-marked point indicating a property entrance point that is on, or close to, the Addressable Object but has been determined independently of it.
 
-For this reason, Geocodes are related to Addresses only in this model, not Addressable Objects, and any Geocode/Addressable Object relations are out-of-scope here.
+For this reason, Geocodes are related only to Addresses in this model, not Addressable Objects, and any Geocode/Addressable Object relations are out-of-scope here.
 
 
 ==== Address Parts
@@ -128,7 +128,7 @@ A model of streets - both naming and some physical presentation of them - has be
 
 There are various given name parts of addresses which have previously been shoved into inappropriate data fields legacy address models and systems. For example, some models have contained _building_ but not _property_ names, so both types have been combined into the field for the former.
 
-In this model, all address parts are just parts with a specialised type indicated with a reference to a concept within a vocabulary such as the Address Parts vocabulary (see <<Supporting Vocabularies>>). Implementations _MUST_ allow for this type of "soft typing" (where a data object's type is selectable from an external list) so that no field limitations such as the above occur.
+In this model, all address parts are just parts with a specialised type indicated with a reference to a concept within a vocabulary such as the Address Parts vocabulary (see <<Vocabularies>>). Implementations _MUST_ allow for this type of "soft typing" (where a data object's type is selectable from an external list) so that no field limitations such as the above occur.
 
 Implementers can limit the part type vocabulary of course and will have to handel all the types they allow in the vocabulary, but implementers should not "make do" with inappropriate field (part type) reuse.
 
@@ -150,7 +150,7 @@ The ability to cater for addresses reachable by watercraft was a requirement of
 
 This model indicates the use of a typed reference from an Address to a Water Feature object, just as Addresses reference Street or Locality objects, and then the Water Feature itself supplies the format of its name, including typing, e.g. Lord Howe _Island_ or Slacks _Creek_ any abbreviations or other name variants, e.g. _Wop pa_ as an indigenous name variant of Great Keppel Island.
 
-This model does not supply the logic for water number generation, just as it does not supply the logic for street number assignment, however it does provide address part types for water-based addressing, see the <<Address Part Types>> in the <<Supporting Vocabularies>> section.
+This model does not supply the logic for water number generation, just as it does not supply the logic for street number assignment, however it does provide address part types for water-based addressing, see the <<Address Part Types>> in the <<Vocabularies>> section.
 
 This model does not provide templating or application logic to show how a water-based address should order water address parts or perhaps use water addressing parts and not street addressing parts: templating logic is exemplified in the templating annex <<AnnexC>> and appropriate part usage logic is left to implementers.
 
@@ -349,7 +349,7 @@ This document is this model's "Specification" which is its authoritative, human-
 | Resource | Role | Notes
 
 | https://linked.data.gov.au/def/addr.ttl[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 expected to be used by this model
+| <<Vocabularies>> | _Vocabulary_ | The codelist vocabularies developed for this model and links to others defined elsewhere but expected to be used by this model
 | <<AnnexA>> | _Guidance_ | The Requirements formally addressed by this model
 | <<AnnexB>> & https://github.com/Spatial-Information-QLD/address-model/blob/main/validator.ttl[Validator] | _Validation_ | The machine-readable validator file used to validate data claiming conformance to this model
 | <<AnnexC>> | _Guidance_ | Suggestions and examples of templating for address presentation