You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 9, 2024. It is now read-only.
Copy file name to clipboardexpand all lines: 03-introduction.adoc
+14-12
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Addresses modelled according to this model do more than just name things though:
14
14
15
15
Overall, this model represents addresses, certain properties for them, including address parts, geocodes and the objects to which addresses are assigned in a conceptual manner similar to the international addressing standard, <<ISO19160-1>>. However, this model is expressed in Semantic Webfootnote:[See https://en.wikipedia.org/wiki/Semantic_Web for a general description of the Semantic Web] form, rather than ISO19160-1's UML and XML, and many aspects of the conceptual range that ISO19160 covers this model does not directly cover but instead delegates to other models which it imports, such as the representation of address and address part lifecycle information. This is done so that common things that this model does are available for use elsewhere via a series of mini-models that others may use without importing this whole model.
16
16
17
-
Additionally, this model relies on several specialised sub-models to handle specific types of address parts, such as roads and geographical object naming. By doing this, those things many be modelled independently of addressing and roads and geographic object names datasets can be used with address data very easily.
17
+
Additionally, this model relies on several specialised sub-models to handle specific types of address parts, such as streets and geographical object naming. By doing this, those things many be modelled independently of addressing and streets and geographic object names datasets can be used with address data very easily.
18
18
19
19
This model makes no attempt to model the things to which addresses are assigned. In the example above, the address "72 Yundah St...." is mentioned as being a form of name for, or assigned to, a cadastral parcel or a 'lot'. This model doesn't know what those things are and leaves their modelling to other systems. This means that using this model alone, you cannot know what an address is for unless you implement an address part to describe the type of object the address is assigned to. This decision has been made since there could be great complexity in spatial object / infrastructure modelling that isn't really core to addressing, so that's best left to other, likely sophisticated, models.
20
20
@@ -38,7 +38,7 @@ Major modelling principles present in this model are:
38
38
. <<Feature / Geometry differentiation>>
39
39
. <<Geocodes>>
40
40
. <<Address Parts>>
41
-
. <<Road & Geographical Names>>
41
+
. <<Street & Geographical Names>>
42
42
. <<Address part typing>>
43
43
. <<Address part templating>>
44
44
. <<Water-based Addressing>>
@@ -80,7 +80,7 @@ This model details the elements of an _address_ but not details of the spatial o
80
80
81
81
This allows for the representation, and ultimately the management, of names - text, numbers, identifiers, references - separately to the management of spatial objects.
82
82
83
-
This Feature / Feature Naming separation applies to Geographical objects, Roads and Administrative Areas as well as Addresses and the first two of those three objects have models similar to this one for their names, <<GN>> & <<ROADS>>.
83
+
This Feature / Feature Naming separation applies to Geographical objects, Streets and Administrative Areas as well as Addresses and the first two of those three objects have models similar to this one for their names, <<GN>> & <<ROADS>>.
84
84
85
85
Some elements of this Feature / Feature Naming pattern, used by this and the two models mentioned above, are captured in the general-purpose _Compound Naming Model_ <<CNM>> which they all inherit from.
86
86
@@ -105,22 +105,22 @@ For this reason, Geocodes are related to Addresses only in this model, not Addre
105
105
106
106
==== Address Parts
107
107
108
-
Addresses are complex things: they are all made of multiple parts with different roles, types ordering and so on. To handle this, this model has a generic notion of a part which may be a simple thing, e.g. a postcode or a street number, but it may also be a complex thing, e.g. a road name that includes a "given" name for the road as well as some type indication.
108
+
Addresses are complex things: they are all made of multiple parts with different roles, types ordering and so on. To handle this, this model has a generic notion of a part which may be a simple thing, e.g. a postcode or a street number, but it may also be a complex thing, e.g. a street name that includes a "given" name for the street as well as some type indication.
109
109
110
-
This model inherits from the Compound Naming Model <<CNM>> which allows for Compound Names, such as Addresses, to link to parts which are also Compound Names which then link to other Compound Names. In this way, Addresses may be "built up" from compound names for a series of parts, such as road names, locality names and so on.
110
+
This model inherits from the Compound Naming Model <<CNM>> which allows for Compound Names, such as Addresses, to link to parts which are also Compound Names which then link to other Compound Names. In this way, Addresses may be "built up" from compound names for a series of parts, such as street names, locality names and so on.
111
111
112
112
113
-
==== Road & Geographical Names
113
+
==== Street & Geographical Names
114
114
115
-
This model can be used to model all the parts of a street names - the 'given' part e.g. "Smith", a type indicator such as "Street" and perhaps a suffix, such as "South" - or it can be used to just indicate that a particular street or road is a part of an address and the name for that road is to be found in an independent road name object.
115
+
This model can be used to model all the parts of a street names - the 'given' part e.g. "Smith", a type indicator such as "Street" and perhaps a suffix, such as "South" - or it can be used to just indicate that a particular street is a part of an address and the name for that street is to be found in an independent object.
116
116
117
-
This second form - delegation of name - is allowed to facilitate point-of-truth road names datasets which both provide names for roads in isolation and are also used by address datasets.
117
+
This second form - delegation of name - is allowed to facilitate point-of-truth datasets which both provide names for streets in isolation and are also used by address datasets.
118
118
119
119
Similarly, names for geographical objects, such as mountains, lakes, certain kinds of locality etc. may also be held independently of addressing data and just referred to as a complex object part of an address.
120
120
121
-
A model of roads - both naming and some physical presentation of them - has been created in parallel to this model, as has a model of Geographical Names which is a replacement for the various Placenames models found in ANZ, such as the https://linked.data.gov.au/def/placenames[FSDF Placenames Ontology]. these models can be used independently as well as within this model. Their persistent web addresses are:
121
+
A model of streets - both naming and some physical presentation of them - has been created in parallel to this model, as has a model of Geographical Names which is a replacement for the various Placenames models found in ANZ, such as the https://linked.data.gov.au/def/placenames[FSDF Placenames Ontology]. These models can be used independently as well as within this model. Their persistent web addresses are:
122
122
123
-
* https://linked.data.gov.au/def/roads - Roads Model
123
+
* https://linked.data.gov.au/def/roads - Streets, called the Roads Model
124
124
* https://linked.data.gov.au/def/gn - Geographical Names Model
125
125
126
126
@@ -148,9 +148,11 @@ While not a core part of this model, templating suggestions are presented in <<A
148
148
149
149
The ability to cater for addresses reachable by watercraft was a requirement of Queensland's project that generated this model. Water-based addressing is standardised in the Australian/New Zealand standard <<AS4189:2011>> and it requires that water-based addressing use the name of the water feature as well as a water address number, the logic for the assignment of which is feature-specific, i.e. numbers for islands and for watercourses are determined differently.
150
150
151
-
This model does not supply the logic for water number generation, just as it does not supply the logic for road number assignment, however it does provide address part types for water-based addressing, see the <<Address Part Types>> in the <<Supporting Vocabularies>> section.
151
+
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.
152
152
153
-
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 road addressing parts: templating logic is exemplified in the templating annex <<AnnexC>> and appropriate part usage logic is left to implementers.
153
+
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.
154
+
155
+
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.
| Definition | A Compound Name is a literal value, or objects that can be interpreted as literal values, that describe or name a Feature
182
182
| Is Defined By | <<CNM>>
183
-
| Scope Note | The basis for the Road Name class. This class is also used for instances of Road Name parts
183
+
| Scope Note | The basis for the Address class. This class is also used for instances of Address Part parts
184
184
|===
185
185
186
186
[[LifecycleStage]]
@@ -194,7 +194,7 @@ ex:addr-1
194
194
| Preferred Label | Compound Name
195
195
| Definition | A Compound Name is a literal value, or objects that can be interpreted as literal values, that describe or name a Feature
196
196
| Is Defined By | <<LM>>
197
-
| 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
197
+
| Scope Note | Used to indicate the lifecycle stage of any Address 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
198
198
|===
199
199
200
200
[[Feature]]
@@ -208,7 +208,7 @@ ex:addr-1
208
208
| Preferred Label | Feature
209
209
| Definition | A discrete spatial phenomenon in a universe of discourse
210
210
| Is Defined By | <<GEO>>
211
-
| Scope Note | Used as the basis for the Road Object class
211
+
| Scope Note | Used as the basis for the Addressable Object class
Copy file name to clipboardexpand all lines: 05-supporting-vocabularies.adoc
+14-26
Original file line number
Diff line number
Diff line change
@@ -18,9 +18,9 @@ NOTE: Hyperlinks to these vocabularies will be provided as soon as persistent id
18
18
19
19
==== Address Part Types
20
20
21
-
This vocabulary is an extended version of <<ISO19160-1>>'s _Address Component Type_ vocabulary.
21
+
This vocabulary is an extended version of <<ISO19160-1>>'s _Address Component Type_ vocabulary and is maintained outside this model. This means it can be extended by the user community (Australian & New Zealand), as needed, and without change to this model.
22
22
23
-
The Persistent web identifier for this vocabulary is:
@@ -36,38 +36,26 @@ The original 8 concepts from ISO19160-1 are:
36
36
| `aptiso:localityName` | locality name | Name of a locality | Use `apt:locality` to refer to a Locality object
37
37
| `aptiso:postOfficeName` | post office name | Name of a post office | Not in current Australian address use
38
38
| `aptiso:postcode` | postcode | Code used for the sorting of mail | Use `apt:postcode`
39
-
| `aptiso:thoroughfareName` | thoroughfare name | Name of a thoroughfare | Use `apt:road` to refer to a road object
39
+
| `aptiso:thoroughfareName` | thoroughfare name | Name of a thoroughfare | Use `apt:street` to refer to a street object
40
40
|===
41
41
42
-
Only the use of `aptiso:postcode` from this list is essentially unchanged as many literal value, such as `countryName`, have been replaced with references to data objects.
42
+
These concepts have all been modified or completely replaced, except `postcode`. Replacements preference links to other complex objects, rather than simple literal data types, for example ISO19160-1's `countryCode` which indicates a text code value for a country has been replaced with `apt:country` which indicates a country object. The use of object references rather than literal values allows for element labelling variation, such as use of abbreviated forms of a name, e.g. "USA" instead of "United Stated of America" , or different language variants, e.g. "Deutschland" instead of "Germany", where the variant information is stored as part of the object referred to.
43
43
44
-
This vocab currently (March, 2024) contains the following terms:
44
+
This vocab currently (June 2024) contains terms such as the following (not the complete vocabulary):
45
45
46
+
[cols="2,3,3,5"]
46
47
|===
47
48
| IRI | Preferred Label | Definition | Scope Note
48
49
49
-
| `apt:geographicalNameObject` | geographical name object | A reference to a geographical name object |
50
-
| `apt:propertyName` | propertyName | A name for a property |
51
-
| `apt:buildingName` | building name | Name of a building |
52
-
| `apt:subaddressType` | sub-address type | | Replaces GNAF's flatTypeCode
53
-
| `apt:subaddressNumber` | sub-address number | | Replaces GNAF's flatNumber
50
+
| `apt:geographicalObject` | geographical name object | A reference to a geographical object | This replaces several ISO19160-1 & GNAF values as this reference can be used to any category of Geographical Object with the name for the object used within the address this part is part of. Geographical Object categories are assgned to the Geographical Object, not any part of this address part or the address it is part of.
51
+
| `apt:subaddressType` | sub-address type | The type of the sub-address part | Replaces GNAF's flatTypeCode
52
+
| `apt:subaddressNumber` | sub-address number | The number of the sub-address part | Replaces GNAF's flatNumber
| `apt:buildingLevelType` | building level type | | Replaces GNAF's levelTypeCode
56
-
| `apt:buildingLevelNumber` | building level number | | Replaces GNAF's levelNumber
57
-
| `apt:buildingLevelNumberSuffix` | building level number suffix | | Replaces GNAF's levelNumberSuffix
58
-
| `apt:streetNumberFirst` | street number first | | Replaces GNAF's numberFirst
59
-
| `apt:streetNumberFirstSuffix` | street number first suffix | | Replaces GNAF's numberFirstSuffix
60
-
| `apt:streetNumberLast` | street number last | | Replaces GNAF's numberLast
61
-
| `apt:streetNumberLastSuffix` | street number last suffix | | Replaces GNAF's numberLastSuffix
62
-
| `apt:street` | street | A reference to a Road object | This replaces streetLocality, streetType in GNAF
63
-
| `apt:waterFeatureNumber` | water feature number | A number given, based on a water feature numbering system |
64
-
| `apt:waterFeatureName` | water feature name | A name given to the water feature |
65
-
| `apt:waterFeatureType` | water feature type | A type for the water feature | From a vocabulary: this part is not expected to be printed
66
-
| `apt:locality` | locality | A reference to a Locality object |
67
-
| `apt:stateOrTerritory` | stateOrTerritory | A reference to a state or territory object |
68
-
| `apt:indigenousCountryName` | indigenous country name | The name of an Indigenous country | Could use the above, if the implementing geographical names data includes indigenous country names
69
-
|`apt:postcode` | postcode | Code used for the sorting of mail |
70
-
| `apt:country` | country | A reference to a country object |
55
+
| ... | ... | ... | ...
56
+
| `apt:locality` | locality | A reference to a Locality object | Replaces ISO19160-1's localityName
57
+
| `apt:waterFeature` | water feature | A reference to a Water Feature object | New in this model
0 commit comments