Foreword
The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of collaborative technologies and tools through open standards.
CalConnect works closely with international and regional partners, of which the full list is available on our website (https://www.calconnect.org/about/liaisons-and-relationships).
The procedures used to develop this document and those intended for its further maintenance are described in the CalConnect Directives.
In particular the different approval criteria needed for the different types of CalConnect documents should be noted. This document was drafted in accordance with the editorial rules of the CalConnect Directives.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CalConnect shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee VCARD.
Introduction
Purpose
Addresses are among the most commonly exchanged information on the Internet, and the interchange of them is crucial to a number of Internet applications, such as electronic commerce, contact exchange, non-postal deliveries, as well as location scheduling.
Yet, addresses can mean much more than just geolocation information:
-
as an identity, such as an office address;
-
as reference points (waypoints) in routing information; and
-
as a delivery point.
The interchange of addresses require a common structure of address data. For instance of a software application in need of user input of address information, users need assistance from the application to enter the correct format and structure of the address for it to be machine readable and interoperable among different machines or systems which process the address data.
This document specifies a set of data models that focuses on enabling software applications the digital interchange of address profiles, address instances and instructions for their input and display suitable for machine encoding of address information. These models are called the “Address Interchange Object” (“AXO”) models.
Furthermore, a registry mechanism is defined to ensure the address profiles can be made publicly available.
Relationship with other parts of the ISO 19160 standards family
This standard complements the other parts in the family of ISO 19160 standards:
-
ISO 19160-1 describes conceptual models for addressing that allow specification of international address profiles. This document further provides methods to utilize these models in a way suitable for digital interchange and storage.
-
ISO 19160-4 defines key terms for postal addressing, postal address components and constraints on their use. It focuses on use cases for postal applications, specifying the methods to write or detect addresses on mail items. This documents adapts models from ISO 19160-1 as address interchange models, to facilitate interchange and interaction of addresses between humans and applications, and between applications, and for applications to interact and interchange international addresses, while supporting human input and human-machine interaction, without loss of fidelity.
-
ISO 19160-5 focuses on the rendering of addresses for different devices with a focus on their representations on maps, virtual and augmented reality. This document focuses on providing an interoperable data model for the interchange and storage of address profiles and addresses, as well as the input and rendering of compliant addresses in a normalized manner. This approach results into a scheme that can be understood across the spectrum of address consumers, including humans, applications, devices and systems.
Address as entered data
The lifecycle of an address entry exchanged on the Internet typically starts with manual input of a human actor. This data, structured or unstructured, is then submitted to an Internet-connected application, and the application may in turn transmit this information to other applications or external parties on behalf of the user who provided the address.
This transmission is usually performed to fulfil service delivery to the user. Within the process, there may be machine-human interactions that require display of the address in human-readable form, as well as machine-to-machine interactions on the address, such as for data validation.
Additional caution shall be placed on the accuracy (or lack thereof) of human input addresses. While an address specified by a human actor may unambiguously distinguish a location, there may be intention or unintentional omissions or additions to an “official” address (if there was one).
Relationship to the addressable object
Attributes of the object which the address points to are considered out of scope of this document, including the AddressableObject model specified in ISO 19160-1.
While considered orthogonal to the AXO models, AddressableObject and other simliar models can easily be used together with the AXO models.
EXAMPLE
In a navigation map, an AXO address can point to an addressable object, in which provides a list of its extant facilities.
Addressing — Digital interchange models
1. Scope
This document specifies a set of data models suitable for machine encoding of address information, called the “Address Interchange Object” (“AXO”) models, and the usage of them.
Specifically, this document provides:
-
data models for digital storage and interchange of address profiles conforming to ISO 19160-1;
-
data models for digital storage and interchange of addresses conforming to a specific address profile;
-
data models for entry and display templates for entering and displaying addresses conforming to the profile and encoding rules above; and
-
the management and operations of a register of address profiles conforming to this document.
Addressability, and features provided within the object which the address points to, is not described in this document. Specifically, the AddressableObject from ISO 19160-1 is considered out of scope.
2. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 19160-1, Addressing – Part 1: Conceptual model
ISO 19103 (all parts), Geographic information – Conceptual schema language
ISO 19106:2004, Geographic information – Profiles
ISO 19115-1, Geographic information – Metadata – Part 1: Fundamentals
ISO 19157 (all parts), Geographic information – Data quality
ISO 19135-1, Geographic information – Procedures for item registration – Part 1: Fundamentals
3. Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 19160-1 and the following apply.
3.1.
lineage
provenance, source(s) and production process(es) used in producing a resource
[SOURCE: ISO 19115-1, Clause 4.9]
3.2.
locale
definition of the subset of a user’s environment that depends on language and cultural conventions
[SOURCE: ISO/IEC/IEEE 9945 (all parts), Clause 4.211, modified — The notes given in ISO/IEC/IEEE 9945 (all parts) for this entry have been omitted.]
3.3.
profile
set of one or more base standards or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options and parameters of those base standards, that are necessary for accomplishing a particular function
[SOURCE: ISO 19106:2004, Clause 4.5]
3.4.
provenance
organization or individual that created, accumulated, maintained and used records
3.5.
data type
specification of a value domain with operations allowed on values in this domain
[SOURCE: ISO 19103 (all parts), Clause 4.14]
3.6.
primitive data type
A data type that has no super type. The primitive data type of a data type is the data type itself, if the data type has no super type, and otherwise the primitive data type of the super type of the data type.
[SOURCE: ISO/IEC 10179:1996, Clause 4.23]
3.7.
interchange address
an address compliant to an interchange address class profile
3.8.
address feature
marking on a profile-compliant address to indicate what it is capable of
3.9.
address layout template
specification of layout and positioning of address components for interchange addresses
3.10.
address display template
address layout template (Clause 3.9) for the display of interchange addresses
3.11.
address form template
address layout template (Clause 3.9) of an input form for the entry of interchange addresses
3.12.
address processor
entity that processes profile-compliant addresses
3.13.
address profile distributor
entity that distributes address profiles
3.14.
signature
the string of bits resulting from the signature process
[SOURCE: ISO/IEC 14888-3, Clause 4.15]
3.15.
signature key
a secret data item specific to an entity and usable only by this entity in the signature process
[SOURCE: ISO/IEC 14888-3, Clause 4.18]
3.16.
verification key
a data item which is mathematically related to an entity’s signature key (Clause 3.15) and which is used by the verifier in the verification process
[SOURCE: ISO/IEC 14888-3, Clause 4.15]
3.17.
object identifier
oid
a value (distinguishable from all other such values) which is associated with an object
[SOURCE: ISO/IEC 15961 (all parts), Clause 3.1.16]
3.18.
language identifier
language symbol
symbol that uniquely identifies a particular language
[SOURCE: ISO 639-3, Clause 3.3]
3.19.
script
set of graphic characters used for the written form of one or more languages
[SOURCE: ISO 15924:2004, Clause 3.7]
3.20.
script code
combination of characters used to represent the name of a script (Clause 3.19)
[SOURCE: ISO 15924:2004, Clause 3.8]
3.21.
URI
uniform resource identifier
[SOURCE: ISO 19103 (all parts), Clause 5.3]
4. Conformance
4.1. General
This part of ISO 19160-6 defines four classes of requirements and conformance. Appendix A specifies how conformance with these classes shall be tested.
4.2. Address profile register
To conform to this standard, an address profile register shall satisfy all of the requirements specified for a register in ISO 19135-1. See Appendix A.2.
4.3. AddressProfile
Any machine-readable description of an ISO 19160-6 AddressProfile for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.3.
4.4. AddressClassProfile
Any machine-readable description of an ISO 19160-6 AddressClassProfile for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.4.
4.5. AddressComponentProfile
Any machine-readable description of an ISO 19160-6 AddressComponentProfile for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.5.
4.6. ProfileCompliantAddress
Any machine-readable description of an ISO 19160-6 ProfileCompliantAddress for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.6.
4.7. ProfileCompliantAddressComponent
Any machine-readable description of an ISO 19160-6 ProfileCompliantAddressComponent for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.7.
4.8. InterchangeAddressClassProfile
Any machine-readable description of an ISO 19160-6 InterchangeAddressClassProfile for which conformance is claimed shall pass all the requirements described in the abstract test suite in Appendix A.8.
4.9. FormTemplate
Any FormTemplate in InterchangeAddressClassProfile model for which FormTemplate conformance is claimed shall pass the requirements described in the abstract test suite in Appendix A.9.
4.10. DisplayTemplate
Any DisplayTemplate in InterchangeAddressClassProfile model for which DisplayTemplate conformance is claimed shall pass the requirements described in the abstract test suite in Appendix A.10.
5. Address profile registry
5.1. General
The ISO address profile registry will be managed with version control software, publicly available with an API and a graphical user interface, such as a web-based interface, to satisfy both programatic and human use for the dissemination, display and management of the registry.
The ISO address profile register is a non-hierarchical register. References to principal registers and sub-registers are excluded from this document.
This address profile registry follows the requirements specified in ISO 19135-1, and additional requirements specified in this standard.
Rules for managing a register of geographical information items, including the submission of information, are found in ISO 19135-1, Clause 6.
NOTE Reference to the ISO 19135-1 requirement is denoted by ɳ (i.e. [ɳ2] = Requirement 2).
5.2. Roles and responsibilities in the management of an address profile registry
The roles and responsibilities of the register owner, register manager, submitting organizations, control body, registry manager and register user are set out in ISO 19135-1.
Requirement 1 [ɳ1]: The register owner shall set terms and conditions regarding different levels of access to the register and making the contents available to the public. In addition, the register owner shall specify the time period in which the approval process shall be completed.
Requirement 2 [ɳ2]: The register owner shall appoint a register manager. A register owner may serve as the register manager for any register that it has established or it may appoint another organization to serve as the register manager.
Requirement 3 [ɳ3]: The register owner shall decide whether a control body is required for the register and if so appoint the control body. The register owner may serve as the control body for any register that it has established or it may delegate that role to a subgroup within the organization or to the register manager.
Requirement 4 [ɳ4]: A register owner shall specify the criteria that determine which organizations may act as submitting organizations.
Requirement 5 [ɳ5]: The register owner shall clarify the process for a submitting organization to appeal decisions of the control body (if such a body is appointed). The register owner may establish a procedure for such a process. The specification of this procedure shall include appropriate time limits for completion of the process. An alternative solution may be for a submitting organization to resubmit a new proposal with changes or a better justification.
Requirement 6 [ɳ6]: A register manager shall manage a register in conformance with ISO 19135-1, Clause 6.
Requirement 7 [ɳ7]: Upon request, the register manager shall distribute an information package containing a description of the register and how to submit proposals for changes to the content of the register. The information package shall describe what proposed changes to the content may be considered to be substantive.
Requirement 8 [ɳ8]: The register manager shall accept proposals from submitting organizations and manage the proposals as specified in ISO 19135-1, Clause 6.4. The register manager shall pass proposals to the control body for decisions as to acceptability and shall serve as the point of contact between the control body and the submitting organization for negotiations regarding changes to the proposal.
Requirement 9 [ɳ9]: The register manager shall determine whether a submitting organization is qualified in accordance with the criteria established by the register owner.
Requirement 10 [ɳ10]: If a control body is appointed, it shall accept proposals from the register manager and render a decision regarding each proposal within the time limits specified by the register owner.
Requirement 11 [ɳ11]: A registry manager shall ensure the integrity of any register held in the registry and shall provide means for electronic access to the registry for register managers, control body members, and register users.
Requirement 12 [ɳ12]: Register managers shall consider the requirements of different categories of users in selecting methods for publishing the content of a register.
Requirement 13: The ISO address profile register shall have a publicly available record of changes where historical content shall remain publicly available.
Submitting organizations for the ISO address profile register consist of organizations and/or persons responsible for defining and maintaining address profiles.
5.3. Unmodified ISO 19135-1:2015 requirements
The unmodified ISO 19135-1 requirements are as follows:
Requirement 14 [ɳ13]: Every register shall have a technical document describing the item classes to be registered.
NOTE For the ISO address profile register that technical document is this document.
Requirement 15 [ɳ14]: Items shall be individually managed, moving through a set of well-defined states. Information about the temporal history of each item shall be maintained.
Requirement 16 [ɳ16]: A clarification shall not cause any substantive semantic or technical change to a registered item.
Requirement 17 [ɳ17]: Clarification shall be accomplished by updating the existing item in the register. The clarification shall be recorded with a justification of the change and the date on which the register transaction was made.
Requirement 18 [ɳ19]: Retirement shall be accomplished by leaving the item in the register, having its status changed to retired, and including the date on which the register transaction was made.
Requirement 19 [ɳ21]: The register manager shall review proposals received from third parties for completeness and return proposals to the submitting organization if the proposal is incomplete or if the submitting organization is not qualified, else initiate the approval process.
Requirement 20 [ɳ22]: The approval process shall be completed within the time period specified by the register owner.
Requirement 21 [ɳ23]: A registry manager shall ensure that information about valid, invalidated, superseded, or retired items in the register is readily available to users.
5.4. Modified ISO 19135-1:2015 requirements
The ISO 19135-1 requirements modified for this document are as follows:
Requirement 22 [ɳ15]: If an item is superseded by another item, the date the succession occurred shall be captured, along with references to and from the item that superseded it. At any given time, only one item in the series should be “valid”.
NOTE 1 The requirement that only one item in the series is “valid” is removed.
Requirement 23 [ɳ20]: If a register item is deemed to be no longer suitable for the use in the production of new data and has been superseded by a new register item, the original item shall remain in the register, shall have its status changed to superseded, have a reference to the item(s) that superseded it, including the date on which the register transaction was made.
NOTE 2 The option of removing a superseded item from the register is removed.
Requirement 24 [ɳ18]: If an item in a register is found to have substantive error, it shall be left in the register, have its status changed to invalid, have a reference to the item(s) that replaced it, and have the date when the register transaction was made.
NOTE 3 The option of removing an invalidated item from the register is removed.
5.5. Specific requirements
Requirement 25: The ISO address profile registry shall follow ISO 19160-1, Clause 6 in the management of address profiles, including the submission of information.
5.6. Content requirements from ISO 19135-1:2015
The ISO address profile register shall conform to the core register schema in ISO 19135-1, Clause 7. This clause sets out specific requirements as follows:
Requirement 26 [ɳ24]: The core register shall conform to the register schema as specified in UML in ISO 19135-1, Clause 7.
Requirement 27 [ɳ25]: The attribute identifier that designates an item class held in a register that conforms to ISO 19135-1, Clause 7, shall uniquely denote the item class within the context of the register.
Requirement 28 [ɳ26]: The attribute itemIdentifier is represented as a CharacterString that is used to uniquely denote that item within an item class and is intended for information processing. Once a value has been assigned, it shall not be reused. The class/identifier union shall be unique within the register.
6. Process of address profile and address interchange
6.1. General
Practical usage of AXO models relies on the establishment of an address profile registry.
This clause sets out specific requirements in relation with ISO 19135-1.
The roles and responsibilities of the register owner, register manager, submitting organizations, control body, registry manager and register user are set out in ISO 19135-1, Clause 5.
Data structures that are shared on the address profile registry include address profiles and their metadata in machine-readable format.
A control body is setup to manage creation of and changes to registered items at the registration authority.
6.2. Address profiles
6.2.1. General
Figure 1 — Lifecycle of an address profile
6.2.2. Creating address profiles and address class profiles
Address class profiles that comply with ISO 19160-1, Annex B, ISO 19106:2004 Conformance class 1, and requirements specified in Clause 10 are created. Address class profiles are created in accordance with requirements specified in Clause 10. Address class profiles are associated with the corresponding address profile in accordance with requirements specified in Clause 10.
6.2.3. Publishing address profiles
Submitting organizations distribute their address profiles to others through direct exchange or through a registry.
6.2.4. Updating address profiles
Submitting organizations can update an address profile and profiles associated with it, and re-distribute it by publishing using a new version number that supersedes the previously published one.
6.2.5. Using address profiles
Applications retrieve suitable address class profiles associated with corresponding address profiles to:
-
render address input forms according to the profile-specified form template; or
-
display addresses according to the profile-specified display template.
Applications shall consider the validity period of an address class profile, and shall periodically check with the submitting organization (or the registry that the submitting organization distributes via) the latest version of the address profile.
6.2.6. Retiring address profiles
Submitting organizations can indicate the validity period of an address class profile in the profile itself, which if the validity end date has passed, would indicate that the profile is retired.
To immediately retire an address class profile, the submitting organization shall distribute a new version of the address profile with an expired validity period.
6.3. Interchange address
6.3.1. General
Figure 2 — Lifecycle of an interchange address
6.3.2. Creating a profile-complaint address
This clause describes how a profile-compliant address is created. The desired address class profile shall be already retrieved for creating a profile-compliant address that conforms to it.
Typically, a user enters an address through an application interface that implements an input format that conforms to the interchange address class profile’s form template, such as an application that runs on an operating system or an Internet application. Such input interface may or may not provide a graphical form.
Conforming applications should not expect general users to be able to input an address with a fully-deduced structure. Immediately after input no features are marked on the interchange address.
6.3.3. Interchange of an interchange address
After a user inputs an address into a structured address form, the user submits this address to the designated recipient, which could be an e-retailer, an electronic business card, or a calendar event.
6.3.4. Displaying an interchange address
The recipient or service that receives an interchange address instance either already has the interchange address class profile or should obtain the interchange address class profile definition. With the interchange address class profile, it could then display the interchange address according to the address class profile’s display template.
6.3.5. Adding address features
6.3.5.1. Improving quality of an interchange address
The recipient or service could process the address, such as to further clean up the address by improving the conformance level by fully deducing the address structure, which would add an address feature https://standards.isotc211.org/19160/-6/features/specified to the address instance.
To ensure that the resulting interchange address with a fully-specified structure is correct, the processor may wish to confirm with the user the resulting address, such as in the case where the address is used for shipping information. This would add the AddressFeature https://standards.isotc211.org/19160/-6/features/confirmed to the address instance.
6.3.5.2. Verifying an interchange address
The recipient or service could further validate the address, such as with a postal or addressing authority. This would add the AddressFeature https://verifyingauthority/verified to the interchange address written by the verifying authority.
6.3.6. Adding associated data to an interchange address
A processor of an interchange address could add extra information such as delivery instructions or routes as associated data.
If the user already has a verified, structured address, then the service could save the effort for verifying the address. Custom address features could be added into the interchange address.
6.3.7. Discarding an interchange address
When a service no longer needs an address, the address should be disposed of.
7. Address profile model overview
The address profile model defined in this document consists of three major layers:
-
the AddressProfile model as a container of profiles of addresses and address components,
-
the profiles of addresses and address components, and
-
the addresses and address components conforming to the profiles of addresses and address components.
The AddressProfile model acts as a container of AddressClassProfiles and AddressComponentProfiles. In general, an AddressProfile contains the AddressClassProfiles and AddressComponentProfiles of a single country or region, which can be represented as country code in ISO 3166-1.
For addresses to conform to this standard, they and their associated address components shall conform to their corresponding AddressClassProfiles and AddressComponentProfiles.
The association between an address and an address components shall also conform to the AddressComponentSpecification defined in between the AddressClassProfile and AddressComponentProfile. Those conforming addresses and address components are ProfileCompliantAddresses and ProfileCompliantAddressComponents.
As ProfileCompliantAddress and ProfileCompliantAddressComponent extend from Address and AddressComponent respectively, their instances will be compliant to ISO 19160-1 without any compatibility issues.
This document further defines InterchangeAddressClassProfile for defining AddressClassProfiles which can be claimed as interchangeable. Addresses compliant to InterchangeAddressClassProfile will be interchangeable among humans, devices and systems with interoperability.
Figure 3 — Address profile model overview in UML
NOTE This clause defines a number of composite data models, integrates and thereby requires coordination between complex precedent standards, including ISO 19115-1, ISO 19160-1 amongst others.
8. Data types
8.1. Primitive and core data types
These are the common data types used within this document.
Primitive data types (PrimitiveTypes) are defined in ISO 19103 (all parts), Clause 7.2, including:
-
CharacterString
-
DateTime, Date, Time
-
Number, Integer, Decimal, Real
-
Vector
-
Boolean
Core data types (CoreTypes) are defined in ISO 19103 (all parts), Clause A.2.
Figure 4 — Data types to be used in this standard
8.2. iso15924Code
The type of written script as defined in ISO 15924:2004.
8.3. iso639Code
This is the value of language code as specified in ISO 639-3.
8.4. iso3166Code
This is the value of country code as specified in ISO 3166-1.
8.5. iso19115CI_Date
The type of CI_Date as defined in ISO 19115-1.
8.6. iso19115PT_Locale
The type of PT_Locale as defined in ISO 19115-1.
8.7. iso19115EX_Extent
The geographic, temporal and vertical information of EX_Extent defined in ISO 19115-1, Clause 6.6.1.
8.8. iso19115MD_Constraints
The constraint information of MD_Constraints as defined in ISO 19115-1.
8.9. iso14888Oid
The public key cryptographic algorithm used for digital signature as defined in ISO/IEC 14888-3.
9. Common models
Figure 5 — Common models to be used in this standard
9.1. Localization
Represents localization metadata of the parent object.
Realized using a PT_Locale object defined in ISO 19115-1, a script code from ISO 15924:2004, a writing system code from ISO/CD 24229, and indication of text direction.
Table 1 — Localization attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| locale | The locale of the parent object. | M | 1 | iso19115PT_Locale |
| script | The type of written script used in the parent object. | M | 1 | iso15924Code |
| writingSystem | The type of writing system used in the parent object. | M | 1 | iso24229Code |
| textDirection | Indicating in which direction the text of the parent should be read. | M | 1 | TextDirectionCode |
9.2. Validity
The time interval where an object is considered valid, with a revision number for issuance date/time.
Table 2 — Validity attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| validityBegins | The date and time when validity starts. | M | 1 | iso19115CI_Date |
| validityEnds | The date and time when validity ends. | M | 1 | iso19115CI_Date |
| revision | Issuance date/time. | M | 1 | iso19115CI_Date |
9.3. Signature
A cryptographic signature used to determine data integrity and validity of the object it belongs to.
Table 3 — Signature attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| algorithm | The public key cryptographic algorithm used for this digital signature. | M | 1 | iso14888Oid |
| publicKey | A reference to the actual public key used to verify the digital signature, a URI where the public key of the signer used for this signature is found. | M | 1 | Uri |
| signature | The actual digital signature value encoded in Base64 format. | M | 1 | CharacterString |
9.4. TextDirectionCode
An enumeration value of TextDirectionCode represents the reading direction of textual data whether it is from left to right or right to left, and from top to bottom or bottom to top.
Table 4 — TextDirectionCode values
| Name | Definition |
|---|---|
| leftToRightTopToBottom | Indicating that text should be read left to right, and top to bottom. |
| rightToLeftTopToBottom | Indicating that text should be read right to left, and top to bottom. |
| leftToRightBottomToTop | Indicating that text should be read left to right, and bottom to top. |
| rightToLeftBottomToTop | Indicating that text should be read right to left, and bottom to top. |
10. Address profile
Figure 6 — Address profile data model
10.1. AddressProfile
Table 5 — AddressProfile attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| country | The country of which this AddressProfile represents. | O | N | iso3166Code |
10.2. AddressClassProfile
An AddressClassProfile represents a profile of a ProfileCompliantAddress. It corresponds to the concept of an AddressClass originally expressed in ISO 19160-1 as a referenced codelist.
It represents additional attributes and restrictions to the ProfileCompliantAddress model. It also represents metadata for the use of the profile.
A single profile can include and support multiple types of address formats, such as a numbered street address and a “PO Box” address simultaneously. Each of these address formats is represented as an interchange address class.
EXAMPLE
The US Numbered Thoroughfare Address with this syntax can be represented as an address class profile:
* { Complete Landmark Name or Complete Place Name }
* { Complete Address Number * }
* { Complete Street Name * }
* { Complete Subaddress }
* { Complete Place Name * }
* { State Name * }
* { Zip Code }
* { Zip Plus 4 }
* { Country Name }
Table 6 — AddressClassProfile attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| id | Unique identifier of this AddressClassProfile. | M | 1 | CharacterString |
| type | Intended usage of this profile. | M | 1 | CharacterString |
| description | Textual description of this profile. | M | 1 | CharacterString |
| localization | The language and script used within this profile. | M | 1 | Localization |
| signature | The digital signature to verify the integrity of this profile, and the identity of the publishing authority. | O | 1 | Signature |
| areaApplicability | The geographic representation of which this AddressClassProfile applies to. Overlapping geographic areas are allowed across different profiles. | O | N | iso19115MD_SpatialRepresentation |
| timeToLive | The maximum time interval between refreshing of this profile via an authoritative source, in seconds. | M | 1 | Integer |
| validity | The period of date and time that this profile should be considered as valid. | M | 1 | Validity |
10.3. AddressComponentProfile
An AddressComponentProfile represents a profile of a ProfileCompliantAddressComponent, which is extended from the AddressComponent model defined in ISO 19160-1.
It represents additional attributes and restrictions to the Address model of a ProfileCompliantAddress. It also represents metadata for the use of the profile.
Table 7 — AddressComponentProfile attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| key | An identifier of this AddressComponentProfile, shall be unique within the AddressProfile. | M | 1 | CharacterString |
| description | Textual description of this component. | M | 1 | CharacterString |
| example | A textual example to demonstrate the correct use of this component. | O | 1 | CharacterString |
10.4. AddressComponentSpecification
An AddressComponentSpecification specifies the cardinalities between a ProfileCompliantAddress and ProfileCompliantAddressComponents.
A ProfileComplinatAddress MUST conform to this AddressComponentSpecification to specifies its components.
Table 8 — AddressComponentSpecification attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| maxCardinality | The maximum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress. | M | 1 | Integer |
| minCardinality | The minimum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress. | M | 1 | Integer |
10.5. AttributeProfile
An AttributeProfile represents name, cardinalities and value type of an attribute in a model that complies with a profile that includes this AttributeProfile.
If it represents an attribute that has been previously defined, e.g. an attribute in Address model defined in ISO 19160-1, it extends the definition of the attribute by redefining the name, cardinalities and value type.
Table 9 — AttributeProfile attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| name | The name of the attribute represented by this AttributeProfile. | M | 1 | CharacterString |
| minCardinality | The minimum number of occurrences of the attribute represented by this AttributeProfile. | O | 1 | Integer |
| maxCardinality | The maximum number of occurences of the attribute represented by this AttributeProfile. | O | 1 | Integer |
| valueType | The data type of values of the attribute represented by this AttributeProfile. | O | 1 | CharacterString |
11. Profile compliant address
Figure 7 — Profile compliant address data model
11.1. ProfileCompliantAddress
ProfileCompliantAddress extends from the Address model defined in ISO 19160-1 to represent an Address complying with an AddressClassProfile.
A ProfileCompliantAddress MUST conform to the constraints and requirements specified in AddressClassProfile, and its associated profiles and specifications.
11.2. ProfileCompliantAddressComponent
ProfileCompliantAddressComponent extends from the AddressComponent model defined in ISO 19160-1 to represent an Address complying with an AddressClassProfile.
A ProfileCompliantAddressComponent MUST conform to the constraints and requirements specified in AddressComponentProfile, and its associated profiles and specifications.
12. InterchangeAddressClassProfile overview
Figure 8 — InterchangeAddressClassProfile model
12.1. InterchangeAddressClassProfile
This InterchangeAddressClassProfile extends from AddressClassProfile to enforce the existence of several subclasses of AttributeProfile for interchange.
It also introduces FormTemplate and DisplayTemplate to to allow the display, entry of, and the interchange of an ProfileCompliantAddress (address instance complying with an InterchangeAddressClassProfile).
12.2. DisplayTemplate
The display template is used for displaying an interchange address instance belonging to an interchange address class. Generally, one address class is represented by one display template.
12.3. FormTemplate
This section shows how an input form can be rendered according to the interchange address class.
The form template should use should also provide an example for display purposes in input (e.g., Help section).
The form template is used for displaying an input form for entry of address data into an interchange address instance. Generally, one address class is represented by one input template.
NOTE This part has no equivalence in PATDL.
12.4. Signature
AttributeProfileSignature extends from AttributeProfile to represent the signature attribute of the object it belongs to.
12.5. AddressFeature
AttributeProfileAddressFeature extends from AttributeProfile to represent the feature attribute of the object it belongs to.
12.6. Validity
AttributeProfileValidity extends from AttributeProfile to represent the validity attribute of the object it belongs to.
13. Address feature
Figure 9 — Address feature data model
13.1. AddressFeature
Address feature represents the status of a particular aspect of an interchange address instance, as determined by an address processor. Each of the aspects may be differentiated by multiple statuses.
This is an abstract class. To represent specific features, this class should be extended upon.
Table 10 — AddressFeature attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| signature | Cryptographic signature used to ensure that the feature is marked by an address process trusted for verification of this feature. The signature generated shall incorporate the id attribute of the interchange address instance that owns it. | O | 1 | Signature |
13.2. SpecificationLevel
When an address is first manually entered by a common person, it is unrealistic to expect this person to fully adhere to the defined structure.
The allowed values of specification levels are:
-
Fully structured, all components are accurately separated and cannot be further split.
-
Partially structured, some components may be structurally correct, but some other components are still unstructured.
-
Unstructured, the user has entered free-form text with no regard of structuring them.
EXAMPLE 1
Digital addresses entered on e-commerce sites and address books are often partially structured, with defined country, region and city, but with street addresses often unstructured.
EXAMPLE 2
Digital addresses for utility installations (e.g. electricity, water supplies) are often fully structured.
Therefore, an organization who accepts these addresses may wish to re-structure them or fill in any missing address components.
Table 11 — SpecificationLevel attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | Indicating the extent of specification of an address instance on its structure. | M | 1 | SpecificationLevelValue |
13.3. QualityStatus
An address entered may not have been validated for correctness. An address processor, such as a postal handling entity, may decide to validate the address to a certain degree in order to determine the correctness of the address.
Table 12 — QualityStatus attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | Indicating the quality of an address instance. | M | 1 | QualityCode |
13.4. Geolocation
An address is commonly linked to one or more geolocations. The value of a location is given by EX_Extent defined in ISO 19115-1, Clause 6.6.1, which supports geographic, temporal and vertical specification.
Table 13 — Geolocation attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | The geographic, temporal and vertical information of the location defined in ISO 19115-1, Clause 6.6.1. | M | 1 | iso19115EX_Extent |
13.5. SpecificationLevelValue
Table 14 — SpecificationLevelValue values
| Name | Definition |
|---|---|
| unstructured | The user has entered free-form text with no regard of structuring them. |
| partial | Some components may be structurally correct, but some other components are still unstructured. |
| full | All components are accurately separated and cannot be further split. |
13.6. QualityCode
Table 15 — QualityCode values
| Name | Definition |
|---|---|
| confirmedCorrect | Indicating that the address is confirmed to be correct to the best of knowledge of the address processor. |
| mostlyCorrect | Indicating with high confidence that the address is correct. |
| possiblyCorrect | Indicating with confidence that the address is correct. |
| structurallyCorrect | Indicating that the address components have the correct value types. |
| unknown | Indicating that this address has not been validated in any way, and it cannot be assigned a quality. |
14. Layout template
Figure 10 — Layout template data model
14.1. LayoutTemplate
The interchange layout template serves as the basis of the interchange display template and the interchange form template.
A layout template is designed to present an interchange address instance in the case of a display template, or present an input form for entry of an interchange address instance in the case of an interchange form template.
The interchange layout template is based on the following assumptions:
-
the resulting layout is displayed in a bounded rectangular area
-
the entire template is in the same script and locale.
The action of inserting components from a given interchange address instance into a layout template is called “render”.
EXAMPLE
A postal mail label can be conceptually considered as an interchange address instance rendered according to a layout template.
Table 16 — LayoutTemplate attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| id | Unique identifier for the layout template. | M | 1 | CharacterString |
| name | Descriptive name of the layout template. | M | 1 | CharacterString |
| description | Textual description of the layout template. | M | 1 | CharacterString |
| localization | Locale and script information of the layout template. | M | 1 | Localization |
| dimension | Physical dimensions of the rectangular bounding box for the rendered layout output. | O | N | LayoutDimension |
| orientation | Horizontal or vertical of the text orientation. | O | 1 | LayoutOrientation |
| lines | The constituent parts of this LayoutTemplate. | O | N | LayoutLine |
14.2. LayoutDimension
Physical dimensions of the rectangular bounding box for the rendered layout output.
Table 17 — LayoutDimension attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| width | The horizontal length of the rectangular bounding box for the rendered layout output. | O | 1 | Integer |
| height | The vertical length of the rectangular bounding box for the rendered layout output. | O | 1 | Integer |
14.3. LayoutOrientation
The enumeration value to indicate the orientation of the address rendered by the LayoutTemplate.
Table 18 — LayoutOrientation values
| Name | Definition |
|---|---|
| horizontal | Indicating that the address will be rendered from left to right or right to left. |
| vertical | Indicating that the address will be rendered from top to bottom or bottom to top. |
15. LayoutLine
Figure 11 — Layout line data model
15.1. LayoutLine
A layout line represents a line in a rendered address display or an address input form.
It forms the basis of the address display line and address form line.
Table 19 — LayoutLine attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| dimensions | Physical dimensions of the rectangular bounding box for the rendered Line. | M | 1 | LayoutDimension |
16. Display template
Figure 12 — Display template data model
16.1. DisplayTemplate
The display template is used for displaying an interchange address instance belonging to an interchange address class. Generally, one address class is represented by one display template.
16.2. DisplayLine
A display line represents a line within a display layout.
16.3. DisplayLineElement
This represents an element within a display line.
16.4. DataElement
Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”.
Table 20 — DataElement attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”. This element indicates that a form field is required, and the data values accepted shall adhere to the data value type defined in its associated interchange address component (through FormLine). | M | 1 | CharacterString |
16.5. TextElement
Representing static text, such as the phrase “PO Box” preceding the actual PO box number, for display layouts for PO boxes.
Table 21 — TextElement attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| text | The actual value of the TextElement. | M | 1 | CharacterString |
17. Form template
Figure 13 — Form template data model
17.1. FormTemplate
This section shows how an input form can be rendered according to the interchange address class.
The form template should use should also provide an example for display purposes in input (e.g., Help section).
The form template is used for displaying an input form for entry of address data into an interchange address instance. Generally, one address class is represented by one input template.
NOTE This part has no equivalence in PATDL.
17.2. FormLine
A form line represents a line within a form layout.
It extends from the LineElementReference model, and takes a set of elements that contain form line element references (FormLineElementReference).
17.3. FormLineElement
This represents an element within a form line.
In an empty form with fields generated from data elements, if the example values of the associated interchange address component are specified, such values should be used as placeholders for form input.
17.4. SelectionPair
Representing a key value pair of a selection, e.g. in the case of the US States, “Rhode Island” is represented as the displayAs attribute and the postal code “RI” is represented as the key attribute.
Table 22 — SelectionPair attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| key | The mapping key as a unique identifier of the key value pair of this SelectionPair. | M | 1 | CharacterString |
| displayAs | The display value of the key value pair of this SelectionPair. | M | 1 | CharacterString |
17.5. SelectionElement
Representing a selectable mapping between display string to code, e.g. in the case of the US States, “Rhode Island” the state name is mapped to the “RI” postal code. Represented by SelectionElement and within SelectionPair.
Table 23 — SelectionElement attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| map | Mapping between a display string to code for each instance of SelectionPair. | M | N | SelectionPair |
17.6. DataElement
Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”.
Table 24 — DataElement attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”. This element indicates that a form field is required, and the data values accepted shall adhere to the data value type defined in its associated interchange address component (through FormLine). | M | 1 | CharacterString |
17.7. StaticTextElement
Static text that can be a constituent part of an ProfileCompliantAddress that complies with an InterchangeAddressClassProfile.
Table 25 — StaticTextElement attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | Representing static text, such as the phrase “PO Box” preceding the actual PO box number, for form layouts for PO boxes. This element is meant to be shown in the form but not allow modification. | M | 1 | CharacterString |
17.8. DataElementWithConditions
DataElementWithConditions extends from DataElement to represent DataElement with additional constraints.
Table 26 — DataElementWithConditions attributes
| Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
|---|---|---|---|---|
| value | The constraint information of MD_Constraint as defined in ISO 19115-1. | M | 1 | iso19115MD_Constraints |
Appendix A
(informative)
Abstract test suites
A.1. Introduction
The abstract test suites for the conformance classes defined by this part of ISO 19160-6 are presented in Appendix A.3 to Appendix A.10.
A.2. Conformance class: Address profile register
Refer to ISO 19135-1 for requirements.
A.3. Conformance class: AddressProfile
Table A.1 — AddressProfile test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
Table A.2 — AddressProfile test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
A.4. Conformance class: AddressClassProfile
Table A.3 — AddressClassProfile test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
Table A.4 — AddressClassProfile test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
A.5. Conformance class: AddressComponentProfile
Table A.5 — AddressComponentProfile test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
Table A.6 — AddressComponentProfile test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 10 |
| Test type | Basic |
A.6. Conformance class: ProfileCompliantAddress
Table A.7 — ProfileCompliantAddress test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 11 |
| Test type | Basic |
Table A.8 — ProfileCompliantAddress test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 11 |
| Test type | Basic |
A.7. Conformance class: ProfileCompliantAddressComponent
Table A.9 — ProfileCompliantAddressComponent test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 11 |
| Test type | Basic |
Table A.10 — ProfileCompliantAddressComponent test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 11 |
| Test type | Basic |
A.8. Conformance class: InterchangeAddressClassProfile
Table A.11 — InterchangeAddressClassProfile test 1: Associations
| Test purpose | Check that the model contains the associations as specified. |
| Test method | Inspect the model |
| Reference | Clause 12 |
| Test type | Basic |
Table A.12 — InterchangeAddressClassProfile test 2: Attributes
| Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 12 |
| Test type | Basic |
A.9. Conformance class: FormTemplate
Table A.13 — FormTemplate test 1: Attributes
| Test purpose | For each class and type in the model, check that the model appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 17 |
| Test type | Basic |
A.10. Conformance class: DisplayTemplate
Table A.14 — DisplayTemplate test 1: Attributes
| Test purpose | For each class and type in the model, check that the model appropriately includes the mandatory, optional and conditional attributes. |
| Test method | Inspect the model |
| Reference | Clause 16 |
| Test type | Basic |
Appendix B
(informative)
Usage
B.1. Accuracy and verification
An authority, such as the local post office, could “verify” a structured address that it is confirmed that this address instance is a “deliverable address” through an AddressFeature.
The owner of the address, such as the tenant of an office, could provide its signed, structured address on an electronic business card. This allows the recipient of the business card to know whether the senders address is authentic. If this address is verified to be a “deliverable address”, the recipient will know that items sent to this address will very likely be deliverable.
Extra steps need to be taken here to allow this.
B.2. Address as identity
Addresses do not only specify a location, in some cases they are part of the identity. For example, in business cards, an address can mean more than just an address, such as with vanity value.
This document shall support this functionality for it to be useful in contact exchange.
This address represents a complete textual address instance.
EXAMPLE 1 — Fully expanded sample address
Suite 1109, Floor 11, Central Building, 1-3 Pedder Street, Central, Central & Western District, Hong Kong Island, Hong Kong
And this address represents the identical address as above, with a reduction of information that is already implied, which that does not reduce its correctness. This can be achieved by supplying a displayTemplate in the interchange address.
EXAMPLE 2 — Shortened sample address
Suite 1109, 1 Pedder Street, Central, Hong Kong
B.3. Address as destination
In certain cases, an address is expected to be reachable either by person and/or post.
An address instance should support being used in conjunction with routing information, acting as a waypoint, and/or supporting a source-defined route.
EXAMPLE
Written instructions on how to deliver to a place can be unambiguous, but terribly difficult to locate. For instance, some buildings have split floors — rooms may have the same floor identifier, but is actually inaccessible from the same floor.
Appendix C
(informative)
Examples of objects specified in this document
Models specified in this document can be represented in various object structures, including in XML ISO/TS 19139:2007 and in JSON.
C.1. AddressProfile
{
"id": "http://standards.isotc211.org/19160/-6/tc211-sample.adp",
"type": "iso-19160-address-profile",
"publisher": "http://standards.isotc211.org/19160/-6/",
"signature": "...",
"name": "TC 211 Minimal Address Profile",
"localization": {
"language": "en",
"script": "en"
},
"area": {
"countries": ["uk"]
},
"valueTypes": {
"addressedObjectIdentifier": {
"primitiveType": "Integer"
}
},
"addressComponents": { ... },
"addressClassProfiles": { ... }
}Figure C.1
C.2. AddressClassProfiles
"addressClassProfiles": {
"streetAddress": {
"description": "Street Address",
"addressComponentSpecifications": [ (AddressComponentSpecification) 1..* ... ]
"displayTemplate": { ... },
"formTemplate": { ... }
}
}Figure C.2
C.3. Validity
"validity": {
"validFrom": "20171129Z000000",
"validTo": "20191129Z000000"
}Figure C.3
C.4. PublisherInformation
"publisher": {
"publisherName": "UK Post Office",
"publisherUri": "https://www.postoffice.co.uk"
}Figure C.4
C.5. Localization
"localization": {
"language": "en",
"script": "Latn"
}Figure C.5
C.6. Signature
"signature": {
"algorithm": "1.2.3.4.5.6.7.8.9",
"publicKey": "https://www.postoffice.co.uk/profile-signature.key",
"signature": "BOLVMNoGNM1TLglnlxgm0a9t"
}Figure C.6
C.7. AddressClassProfile
"addressClassProfile": {
"id": "streetAddress",
"description": "A typical street address",
"addressComponentSpecifications": [ ... ],
"displayTemplate": { ... },
"formTemplate": { ... },
}Figure C.7
C.8. User Defined Data Types
"valueTypes": [{
"name": "addressNumberValue",
"coreType": "Integer",
"constraints": [ ... ],
}]Figure C.8
C.9. Data Type Constraints
"constraints": [{
"maxValue": 10000,
"minValue": 1
}]Figure C.9
C.10. AddressComponentClass
"addressComponentClass": {
"key": "addressNumber",
"description": "Street number",
"datatype": "addressNumberValue"
}Figure C.10
C.11. ProfileCompliantAddress
"address": {
"profileId": "https://standards.isotc211.org/19160/-6/profiles/uk.adp",
"components": [ ... ],
"signature": { ... },
"features": [ ... ]
}Figure C.11
C.12. AddressComponent
"addressComponent": {
"type": "addressNumber",
"values": [ 1001 ]
}Figure C.12
C.13. AddressFeature
"addressFeature": {
"feature": "https://standards.isotc211.org/19160/-6/features/specified",
"signature": [ ... ]
}Figure C.13
C.14. DisplayTemplate
DisplayTemplate: {
...
}Figure C.14
C.15. FormTemplate
FormTemplate: {
...
}Figure C.15
Appendix D
(informative)
Examples
D.1. Example of address profiles defined in ISO 19160-1
D.1.1. ISO 19160-1 C.2 Example 1: Minimal address profile
D.1.1.1. Address profile (JSON)
{
"id": "http://standards.isotc211.org/19160/-6/tc211-minimal.adp",
"type": "iso-19160-address-profile",
"publisher": "http://standards.isotc211.org/19160/-6/",
"signature": "...",
"name": "TC 211 Minimal Address Profile",
"locale": {
"language": "en",
"script": "Latn"
},
"addressComponents": {
"addressLine": {
"dataType": "CharacterString",
"minCardinality": 1
},
},
"addressClassProfiles": {
"minimalAddress": {
"addressComponentSpecifications": [
{
"componentType": "addressLine",
"description": "Address line",
"require": true
}
],
"displayTemplates": [
{
"id": "basic",
"name": "Basic",
"description": "Rendering of the minimal address profile",
"orientation": "horizontal",
"localization": {
"script": "Latn",
"language": "en"
},
"lines": [
{
"componenet": "addressLine",
"cardinality": "*"
}
]
}
],
"formTemplates": [
{
"id": "basic",
"name": "Basic",
"description": "Address input form for the minimal address profile",
"orientation": "horizontal",
"localization": {
"script": "Latn",
"language": "en"
},
"formLines": [
{
"fields": [
{ "component": "addressLine" }
],
"cardinality": "*"
}
]
}
]
}
}
}Figure D.1
D.1.1.2. Profile-compliant address (ISO 19160-1, Figure C.3, South African street address) (JSON)
{
"profile": "http://standards.isotc211.org/19160/-6/tc211-minimal.adp",
"components": [
{
"type": "addressLine",
"value": "14 Church Street"
},
{
"type": "addressLine",
"value": "Hatfield"
},
{
"type": "addressLine",
"value": "South Africa"
}
]
}Figure D.2
D.1.1.3. Profile-compliant address (ISO 19160-1, Figure C.4, US landmark address) (JSON)
{
"profile": "http://standards.isotc211.org/19160/-6/tc211-minimal.adp",
"components": [
{
"type": "addressLine",
"value": "Statue of Liberty"
},
{
"type": "addressLine",
"value": "Liberty Island"
},
{
"type": "addressLine",
"value": "New York"
},
{
"type": "addressLine",
"value": "NY"
}
]
}Figure D.3
D.1.1.4. Profile-compliant address (ISO 19160-1, Figure C.5, UK address) (JSON)
{
"profile": "http://standards.isotc211.org/19160/-6/tc211-minimal.adp",
"components": [
{
"type": "addressLine",
"value": "Multi-storey car park at Southampton Magistrates Court"
},
{
"type": "addressLine",
"value": "Carlton Crescent"
},
{
"type": "addressLine",
"value": "Southampton, Bevois"
},
{
"type": "addressLine",
"value": "S017 1EY"
},
{
"type": "addressLine",
"value": "United Kingdom"
}
]
}Figure D.4
D.1.2. ISO 19160-1 C.3 Example 2: Sample address profile
D.1.2.1. Address profile (JSON)
profile = {
"id": "http://standards.isotc211.org/19160/-6/tc211-sample.adp",
"type": "iso-19160-address-profile",
"publisher": "http://standards.isotc211.org/19160/-6/",
"signature": "...",
"name": "TC 211 Minimal Address Profile",
"locale": {
"language": "en",
"script": "en"
},
"valueTypes": {
"addressedObjectIdentiferValue": {
"primitiveType": "Integer",
"maxValue": 10000,
"minValue": 1
},
"thoroughfareNameValue": {
"type": "Object",
"value": {
"prefix": {
"primitiveType": "CharacterString"
},
"name": {
"primitiveType": "CharacterString"
},
"suffix": {
"primitiveType": "CharacterString"
},
"type": {
"primitiveType": "CharacterString"
}
}
}
}
"addressComponents": {
"addressNumber": {
"dataType": "addressedObjectIdentiferValue",
"description": "Address number"
},
"boxNumber": {
"dataType": "addressedObjectIdentiferValue",
"description": "PO Box number"
},
/* Table C.4. Address component type */
"thoroughfareName": {
"dataType": "thoroughfareNameValue",
"description": "Thoroughfare name"
},
"localityName": {
"dataType": "CharacterString",
"description": "Locality name"
},
"postOfficeName": {
"dataType": "CharacterString",
"description": "Post office name"
},
"postCode": {
"dataType": "CharacterString",
"description": "Post code"
},
"countryName": {
"dataType": "CharacterString",
"description": "Country"
}
},
"addressClassProfiles": {
"streetAddress": {
"description": "Street Address",
"addressComponentSpecifications": [
{
"componentType": "addressNumber",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "thoroughfareName",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "placeName",
"dataType": CharacterString,
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "postCode",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "countryName",
"minCardinality": 1,
"maxCardinality": 1,
"required": false,
},
],
"displayTemplates": [
{
"id": "basic",
"name": "Basic",
"description": "Rendering of the minimal address profile",
"orientation": "horizontal",
"localization": {
"script": "Latn",
"language": "en"
},
"lines": [
{
"type": "template",
"value": "{{ addressNumber }} {{ thoroughfareName.name }} {{ thoroughfareName.type }}"
},
{
"type": "template",
"value": "{{ placeName }} {{ postCode }}"
},
{
"type": "component",
"value": "countryName"
}
]
}
],
"formTemplates": [
{
"id": "basic",
"name": "Basic",
"description": "Address input form for the sample address profile",
"orientation": "horizontal",
"localization": {
"script": "Latn",
"language": "en"
},
"formLines": [
{
"fields": [
{ "component": "addressNumber" },
{ "component": "thoroughfareName" }
]
},
{
"fields": [
{ "component": "placeName" },
{ "component": "postCode" }
]
},
{
"fields": [
{ "component": "countryName" }
]
}
]
}
]
},
"boxAddress": {
"addressComponentSpecifications": [
{
"componentType": "boxNumber",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "postOfficeName",
"dataType": "CharacterString",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "postCode",
"minCardinality": 1,
"maxCardinality": 1,
"required": true
},
{
"componentType": "countryName",
"minCardinality": 1,
"maxCardinality": 1,
"required": false
},
],
"displayTemplates": [
{
"id": "basic",
"name": "Basic",
"description": "Rendering of the minimal address profile",
"orientation": "horizontal",
"localization": {
"script": "Latn",
"language": "en"
},
"lines": [
{
"type": "template",
"value": "PO Box {{ boxNumber }}"
},
{
"type": "component",
"value": "postOfficeName"
},
{
"type": "component",
"value": "postCode"
},
{
"type": "component",
"value": "countryName"
}
]
}
],
"formLines": [
{
"fields": [
{ "component": "boxNumber" }
]
},
{
"fields": [
{ "component": "postOfficeName" }
]
},
{
"fields": [
{ "component": "postCode" }
]
},
{
"fields": [
{ "component": "countryName" }
]
}
]
}
}
}Figure D.5
D.1.2.2. Profile-compliant address (ISO 19160-1, Figure C.14, Street address) (JSON)
/* streetAddress */
{
"profile": "http://standards.isotc211.org/19160/-6/tc211-sample.adp#streetAddress",
"components": [
{
"type": "addressNumber",
"value": "99"
},
{
"type": "thoroughfareName",
"value": {
"name": "Lombardy",
"type": "Street"
}
},
{
"type": "placeName",
"value": "The Hills"
},
{
"type": "postCode",
"value": "0039"
},
{
"type": "countryName",
"value": "South Africa"
}
]
}
Figure D.6
D.1.2.3. Profile-compliant address (ISO 19160-1, Figure C.15, Box address) (JSON)
/* boxAddress */
{
"profile": "http://standards.isotc211.org/19160/-6/tc211-sample.adp#boxAddress",
"components": [
{
"type": "boxNumber",
"value": "345"
},
{
"type": "postOfficeName",
"value": "Orlando"
},
{
"type": "postCode",
"value": "2020"
},
{
"type": "countryName",
"value": "South Africa"
}
]
}
Figure D.7
Bibliography
[1] ISO 639-3, Codes for the representation of names of languages – Part 3: Alpha-3 code for comprehensive coverage of languages
[2] ISO 3166-1, Codes for the representation of names of countries and their subdivisions – Part 1: Country codes
[3] ISO/IEC/IEEE 9945 (all parts), Information technology – Portable Operating System Interface (POSIX®) Base Specifications, Issue 7
[4] ISO/IEC 14888-3, IT Security techniques – Digital signatures with appendix – Part 3: Discrete logarithm based mechanisms
[5] ISO 15924:2004, Information and documentation – Codes for the representation of names of scripts
[6] ISO/IEC 15961 (all parts), Information technology – Radio frequency identification (RFID) for item management
[7] ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation
[8] ISO 19160-4, Addressing – Part 4: International postal address components and template language
[9] ISO/CD 24229, Information and documentation – Codes for script conversion systems
[10] ISO/IEC/IEEE 31320-2, Information technology – Modeling Languages – Part 2: Syntax and Semantics for IDEF1X97 (IDEFobject)
[11] ISO/IEC 10179:1996, Information technology – Processing languages – Document Style Semantics and Specification Language (DSSSL)