Merge pull request #2 from icsm-au/vocabs-update

Vocabs 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
@@ -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

04-model.adoc

@@ -75,7 +75,7 @@ PREFIX schema: <https://schema.org/>
     ] ;
     addr:hasGeocode [
         a addr:Geocode ;
-        schema:roleName <https://linked.data.gov.au/def/geocode-types/property-centroid> ;
+        schema:additionalType <https://linked.data.gov.au/def/geocode-types/property-centroid> ;
         geo:asWKT "POINT(153.0846 -27.3270)"^^geo:wktLiteral ;
     ] ;
     cn:isNameFor ex-parcel:161162441 ;
@@ -141,7 +141,7 @@ ex:cadastral-parcel-x
 | Subclass Of | <<Geometry>>
 | Provenance | Derived from the G-NAF's expression of Address position
 | Scope note | Indicating a Geocode for an Address is a direct method of positioning the Address on the earth. Addresses may also be located by reference to an Addressable Object whc=ich is an indirect method. This model does not indicate any Geocode / Addressable Object geometry relations, although they may exist
-| Expected Properties | <<roleName>> - use to indicate the role that a Geocode plays in relation to an Address, <<hasSerialization, hasSerialization>> - use to indicate the position information of the Geocode
+| Expected Properties | <<additionalType>> - use to indicate the specialised type of a Geocode, <<hasSerialization, hasSerialization>> - use to indicate the position information of the Geocode
 
 `geo:hasGeometry` - to indicate the position of the Geocode. A GeoSPARQL `Geometry`.
 | Example
@@ -151,7 +151,7 @@ a| [source,turtle]
 ex:addr-1
   a addr:Address ;
   addr:hasGeocode [
-    schema:roleName addr:buildingAccessPoint ;
+    schema:additionalType addr:buildingAccessPoint ;
     geo:asWKT "POINT (152.01 -35.03)"^^geo:wktLiteral ;  # specialised form of hasSerialization
   ] ;
   ...
@@ -295,7 +295,6 @@ ex:addr-1
 * <<value>>
 * <<additionalType>>
 * <<hasPart>>
-* <<roleName>>
 * <<hasGeometry>>
 * <<hasSerialization>>
 
@@ -443,20 +442,6 @@ ex:street-name-x
 | Scope Note | Used to indicate the parts of a Address
 |===
 
-[[roleName]]
-==== roleName
-
-[cols="2,6"]
-|===
-| Property | Value
-
-| IRI | `schema:roleName`
-| Preferred Label | role name
-| Definition | A role played, performed or filled by a person or organization
-| Is Defined By | <<SDO>>
-| Scope Note | Used to indicate the role that a Geocode place in relation to an Address
-|===
-
 [[hasGeometry]]
 ==== hasGeometry
 

05-supporting-vocabularies.adoc → 05-vocabularies.adoc

@@ -1,10 +1,29 @@
-== Supporting Vocabularies
+== Vocabularies
 
-This model uses many vocabularies to give specialised types and roles to classes. This section previews some vocabularies that may be used and links to some others.
+This model requires the use of vocabularies to provide values for some predicates. Values from a Geocode role type vocabulary must be used to provide value for a Geocode's <<additionalType>> predicate indicating the role that a Geocode plays, and similarly, values from a lifecycle stages vocabulary must be used to provide values for a Lifecycle Stage's <<additionalType>> predicate, indicating specialised lifecycle stage type. <<additionalType>> is frequently use to provide specialised typing for instances of classes.
 
-This section is not to be taken as normative: these are example vocabularies and, even then, only part of them, to assist with model use.
+[NOTE]
+See the example for <<Address>> where vocabulary concepts are used for both Geocode's and Lifecycle Stage's <<additionalType>> predicates.
 
-When implementing this model, it is within the remit of implementation-specific validators to mandate certain vocabularies and perhaps subsets fo concepts within those vocabularies, for use.
+Wherever in the model the range value for a predicate is given as a `skos:Concept`, this indicates that a vocabulary must be used as opposed to literal (text, numerical) values. `skos:Concept` objects are presented within `skos:ConceptScheme` resources, which are controlled vocabularies.
+
+Particular vocabularies _MUST_ be used within certain contexts of use of this model. The following subsections per known use context indicate which particular vocabularies must be used, where.
+
+=== ICSM Australia & New Zealand Address Data Exchange
+
+When address information formulated according to this model is exchanged within Australia & New Zealand according to the https://www.icsm.gov.au[Intergovernmental Committee on Surveying & Mapping]'s rules, the following predicates _MUST_ have range values selected from the indicated vocabularies.
+
+
+|===
+| Model | Class | Predicate | Vocabulary
+
+| Address Model | <<Address>> | <<hasPart>>/<<additionalType>> | https://linked.data.gov.au/def/geocode-types[ICSM's Address Part Types]
+| Address Model | <<Geocode>> | <<additionalType>> | https://linked.data.gov.au/def/geocode-types[ICSM's Geocode Roles]
+
+| Lifecycle Model | Lifecycle Stage | <<additionalType>> | https://linked.data.gov.au/def/lifecycle-stage-types[ICSM's Lifecycle Stage Types]
+|===
+
+//// get the remainder from Anne's documents
 
 === Vocabularies previewed here
 
@@ -108,11 +127,3 @@ The Persistent web identifier for this vocabulary is:
 | `gt:service-meter` | Service Meter | The utility meter (e.g. box, or underground chamber)
 | `gt:unit-centroid` | Unit Centroid | Point at centre of unit and lying within its bounds (e.g. for u-shaped unit)
 |===
-
-=== Links to other vocabularies
-
-Multiple vocabularies derived from existing standards' codelists and databases' lookup table have been created for use with this model and proposed for adoption in vocabulary form to the Intergovernmental Committee on Surveying & Mapping (ICSM). Those vocabularies, such as _Address Status Type_, _Level Types_ etc. can be seen online at:
-
-* https://gsq-prez.dev.kurrawong.ai/v#qsi-vocabs[QSI's development vocab server]
-
-See all the vocabularies with Theme: Geocoded Addressing