Working Draft

CalConnect Standard

CC/WD 19160-6:2019
Addressing — Digital interchange models
TC VCARD
Ronald TseAuthor
CalConnect Standard
Working Draft

Warning for Drafts

This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

 


 



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:

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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
localeThe locale of the parent object.M1 iso19115PT_Locale
scriptThe type of written script used in the parent object.M1 iso15924Code
writingSystemThe type of writing system used in the parent object.M1 iso24229Code
textDirectionIndicating in which direction the text of the parent should be read.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
validityBeginsThe date and time when validity starts.M1 iso19115CI_Date
validityEndsThe date and time when validity ends.M1 iso19115CI_Date
revisionIssuance date/time.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
algorithmThe public key cryptographic algorithm used for this digital signature.M1 iso14888Oid
publicKeyA 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.M1 Uri
signatureThe actual digital signature value encoded in Base64 format.M1 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

NameDefinition
leftToRightTopToBottomIndicating that text should be read left to right, and top to bottom.
rightToLeftTopToBottomIndicating that text should be read right to left, and top to bottom.
leftToRightBottomToTopIndicating that text should be read left to right, and bottom to top.
rightToLeftBottomToTopIndicating 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
countryThe country of which this AddressProfile represents.ON 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
idUnique identifier of this AddressClassProfile.M1 CharacterString
typeIntended usage of this profile.M1 CharacterString
descriptionTextual description of this profile.M1 CharacterString
localizationThe language and script used within this profile.M1 Localization
signatureThe digital signature to verify the integrity of this profile, and the identity of the publishing authority.O1 Signature
areaApplicabilityThe geographic representation of which this AddressClassProfile applies to. Overlapping geographic areas are allowed across different profiles.ON iso19115MD_SpatialRepresentation
timeToLiveThe maximum time interval between refreshing of this profile via an authoritative source, in seconds.M1 Integer
validityThe period of date and time that this profile should be considered as valid.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
keyAn identifier of this AddressComponentProfile, shall be unique within the AddressProfile.M1 CharacterString
descriptionTextual description of this component.M1 CharacterString
exampleA textual example to demonstrate the correct use of this component.O1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
maxCardinalityThe maximum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress.M1 Integer
minCardinalityThe minimum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
nameThe name of the attribute represented by this AttributeProfile.M1 CharacterString
minCardinalityThe minimum number of occurrences of the attribute represented by this AttributeProfile.O1 Integer
maxCardinalityThe maximum number of occurences of the attribute represented by this AttributeProfile.O1 Integer
valueTypeThe data type of values of the attribute represented by this AttributeProfile.O1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
signatureCryptographic 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.O1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
valueIndicating the extent of specification of an address instance on its structure.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
valueIndicating the quality of an address instance.M1 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

NameDefinitionMandatory/ Optional/ ConditionalMax OccurData Type
valueThe geographic, temporal and vertical information of the location defined in ISO 19115-1, Clause 6.6.1.M1 iso19115EX_Extent

13.5.  SpecificationLevelValue

Table 14 — SpecificationLevelValue values

NameDefinition
unstructuredThe user has entered free-form text with no regard of structuring them.
partialSome components may be structurally correct, but some other components are still unstructured.
fullAll components are accurately separated and cannot be further split.

13.6.  QualityCode

Table 15 — QualityCode values

NameDefinition
confirmedCorrectIndicating that the address is confirmed to be correct to the best of knowledge of the address processor.
mostlyCorrectIndicating with high confidence that the address is correct.
possiblyCorrectIndicating with confidence that the address is correct.
structurallyCorrectIndicating that the address components have the correct value types.
unknownIndicating that this address has not been validated in any way, and it cannot be assigned a quality.

14.  Layout template