Business overview

This section provides a business level overview of this capability.

This capability allows various types of Location_representation to be represented. Each may be associated with a Location through a Location_assignment (see C049: assigning_location), to establish the Location for which it is a representation of. The rules used to determine what actually constitutes a Location are out of scope for this Capability, as, generally, they will be specific to the business needs of the authority assigning the Location Identifier. As a generic concept, a Location should be defined as a bound polyhedron. However, for simplicity, such a location polyhedron can be reduced to a single point in space and still satisfy most business needs. When viewed in this manner, a Location can be defined by at least one from the list of :

• a global position, expressed in terms of latitude, longitude and altitude;
• a reference to a locally established grid;
• the specification of an organizational based code;
• the specification of a postal address, including nested addresses;
• the specification of product based codes, identifying a node in a product breakdown structure or a zone within a product, including nested locations;
• relationship to another location.

This Capability should not be used to describe location within product geometry.

Information model overview

This section provides an overview of the information model that supports this capability.

The information required to represent a Location and Location_representation is summarized in the diagram at Figure 1 below. Details to describe a Location are provided in a separate capability - namely C049: assigning_location which is designed to provide a simple representation. In the following sections, this capability provides guidance on the different alternative Location_representations outlined above.

Figure 1 —  Representation of a Location

Location Identification

All locations are given a common name. While this will usually take the form of a plain language string, it is usual for naming authorities to support this with the assignment of some form of formated identifier, suitable for automated processing. Each location may acquire several such identifiers to meet the different needs of the various authorities.

Location

Each instance of Location shall be identified through the assignment of an identifier which has been classified as an "Location identification code" (urn:plcs:rdl:std:Location identification code). This may, for example, be the name associated with a location and can be provided through the use of the template assigning_identification_with_no_organization.

Each instance of Location shall optionally be assigned a classification of[Location_type_code]
Error RDL1: The class Location_type_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
. This allows, for example, the location to be characterized using specialisations of this class - see C049: assigning_location for details.

Location Assignment

The assigned Location represents a place or position where an Activity or Event can occur, or where a Product or Resource_item can exist. The role that the Location plays in these contexts can be given by classifying the Location_assignment as a type of "Location assignment role" (urn:plcs:rdl:std:Location assignment role). The purpose of the assignment will depend upon each business-specific use but there are several generic sub-classes which may be used (and specialised further where and when necessary). See C049: assigning_location for details.

Alternates

Each Location may have zero or more alternative_location_representations, and is therefore an optional attribute of location. The subtypes of Location_representation provide the alternative representations of the Location defined and are represented using capability C027: representing_location.

NOTE    These alternatives are meant to be alternative representations of the same place defined by the instance of Location that they are an attribute of. For different Locations see the guidance below about "Alternative location" (urn:plcs:rdl:std:Alternative location)s.

Location Representation

Because the concept of a Location is very human, many alternative ways exist as to how it can be represented. These Location_representations offer alternatives in communicating about a location. A strict representation would require the location to be defined by the points of the polyhedron that bounds it. However, only the most demanding users, such as map makers, require this degree of precision. In general, most users are more comfortable with the concept of "place", which can be considered as a notional (and probably undeclared) polyhedron, but which is sufficiently well understood, when associated with one or more identifiers, to serve the business need.

Traditionally, the process of providing a location with an identify has been relatively informal and undisciplined. However, increasing automation is requiring progressively more accurate and consistent representation of the information required to define a location unambiguously for interpretation by machine. The next sections describe each of the different six ways a location may be represented. However, they all have certain aspects in common which shall be described first.

Identification of the Representation

Each instance of Location_representation can be identified through the assignment of an identifier which is a (relevant) sub-classification of "Location identification code" (urn:plcs:rdl:std:Location identification code). For example,

• "Organizational location identification code" (urn:plcs:rdl:std:Organizational location identification code) - i.e. the location within the context of the relevant Organization.
• "Geographic location identification code" (urn:plcs:rdl:std:Geographic location identification code) - i.e. the location within the context of a geographical coordinate system
• "Address based location identification code" (urn:plcs:rdl:std:Address based location identification code) - i.e. the location within the context of a postal address
• [Product_location_identification_code]
  Error RDL1: The class Product_location_identification_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  - i.e. the location within the context of a product or product version
• "Regional grid location identification code" (urn:plcs:rdl:std:Regional grid location identification code) - i.e. the location at a coordinate within a grid

These are associated with the Location_representation through the use of the template assigning_identification_with_no_organization defined within the capability C001: assigning_identifiers.

Classification of the Representation

A Location_representation may additionally be classified by a Classification_assignment using the template assigning_reference_data to provide additional sub-classes of Location_representation. However, the existing subtypes of Location_representation and subclasses provided above should be used in the first instance. Extending the subclasses according to business specific usage is acceptable and should use the subclasses provided for extensions when and if necesssary. Generally, the codes provided are available to classify both identifiers (discussed above) and for classification of the Location_representations when required. However, it is not required to classify the subtypes of Location_representation above unless a further refinement of one of these classes has been determined. Other sub-classifications can be represented by this capability through the extension of the reference data classes above. See capability C010: assigning_reference_data for details.

Organization Based Codes

An Organization_based_location_representation takes the form of an Organizational_location_identification that is only valid and meaningful in the context of the organization that has assigned it. Classically, these would take the form of name assignments for geographic features of temporary interest, for example "Hill 90".

The representation of an Organization_based_location_representation can be provided through the use of the template representing_organizational_location defined below.

Global Position

A Global_location_representation defines an absolute position by reference to the geodetic latitude and longitude grid, usually based on the equator and the Greenwich Meridian. To obtain a three dimensional fix, as required, for example, to locate an aircraft in flight, it is also necessary to define an altitude. This is traditionally specified with relation to height above sea level, with negative values indicating a depth.

The representation of an Global_location_representation can be provided through the use of the template representing_geographical_location defined below.

Local Grid

An alternative to the Global Position reference can be achieved by a Regional_grid_location_representation. The most common form of local grids are those established by cartographers and superimposed on their maps. To provide an unambiguous identification, all partners must have access to the definition of the grid origin and orientation.

The representation of an Regional_grid_location_representation can be provided through the use of the template representing_grid_location defined below.

Postal Address

The most common form of location definition is the Address_based_location_representation. Postal Addresses are, generally, assigned by the national postal authority, with the agreement of the local administrative authority, and published in gazetteers.

The representation of an Address_based_location_representation can be provided through the use of the template representing_address_location defined below.

Product Based Codes

A Product_based_location_identification is used to determine a location within a product structure. In a simple environment, an example could be "the port outer engine". More complex allocations require a reference to the product breakdown structure, including version information, to ensure an unambiguous definition.

The representation of an Product_based_location_identification can be provided through the use of the template representing_product_location
Error T1: DEX representing_product_location not in Dexlib
defined below.

Location Hierarchy

It is sometimes appropriate to identify a Location by reference to another, better defined, Location. For example, it is common maritime practice to define a position by a range and bearing from a known reference point. When this method of location identification is employed, it is necessary for the Location_relationship to be unambiguously defined.

However, there is no relationship in the model between instances ofLocation_representation which indicates that this must be between instances ofLocation and if still required, the different alternative Location_representations can be determined from them. This relationship is described with capability C049: assigning_location.

In short the relationship between two Location instances may be represented using an instance of Location_relationship. The meaning of the relationship can be provided through a classification of the relationship using the template assigning_reference_data. The classification should be a type of "Location relationship role" (urn:plcs:rdl:std:Location relationship role).

C049: assigning_location defines the sub-classes of "Location relationship role" (urn:plcs:rdl:std:Location relationship role) but for the purpose of this section, the class [Relative_to_relationship]
Error RDL1: The class Relative_to_relationship does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
may be used. i.e. a classification of a Location_relationship where a different, related_location (dependant) is defined relative to the relating_location. This type of relationship is frequently used for nautical and orienteering purposes. E.g. providing a bearing relative to a fixed position or grid).

NOTE    To represent both a range and bearing, two instances of Regional_coordinate would be required.

Model Characterization

This section specifies how the information model can be further characterized by the assignment of additional information such as dates, approvals and people or organizations.

The following characterizations may apply.

Characterization: Timing of the Representation (Optional)

A Location_representation may additionally be characterized by a Calendar_date, or Date_time, through a Date_or_date_time_assignment. The role of the assignment should describe the purpose of the date or time representation used through relevant reference data. Typical classifications include any of the reference data whose root classification is associated with Date_or_date_time_assignment is permissible, such as;

• "Date actual" (urn:plcs:rdl:std:Date actual) - i.e. the location within the context of the relevant Organization.
• "Date actual observation" (urn:plcs:rdl:std:Date actual observation) - i.e. the location within the context of a geographical coordinate system
• "Date planned" (urn:plcs:rdl:std:Date planned) - i.e. the location within the context of a postal address
• [Date_planned_observation]
  Error RDL1: The class Date_planned_observation does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  - i.e. the location at a coordinate within a grid
• [Date_predicted]
  Error RDL1: The class Date_predicted does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  - i.e. the location within the context of a product or product version

For example, a "Date actual observation" (urn:plcs:rdl:std:Date actual observation) may be required for establishing the time associated with a particular location (such as a global postition) which can be compared with subsequent readings to compute further information, such as speed.

This list is not definitive (nor meant to be). See capability C010: assigning_reference_data for details. It is anticipated that more specific sub-classes of reference data may be produced for with specific business usage requirements.

Characterization: Activity Assignment and the Representation (Optional)

A Location_representation may also be referenced by a Applied_activity_assignment using the template assigning_activity defined within capability C032: representing_activity. This may provide an additional representation of the location where the referenced Activity may take place.

However, the preferred mechanism for defining a location for this purpose is through the use of an instance of Location as described in C020: representing_life_cycle_opportunity. In this situation, the Location_representation should be treated as an alternative representation in addition to the Location as shown in Figure 1, and described above.

Characterization: Additional Identification (Optional)

Each instance of Location_representation may have additional identifiers assigned through the assignment of an identifier which is a (relevant) sub-classification of "Location identification code" (urn:plcs:rdl:std:Location identification code). For example,:

• "Organizational location identification code" (urn:plcs:rdl:std:Organizational location identification code) - i.e. the location within the context of the relevant Organization.
• "Geographic location identification code" (urn:plcs:rdl:std:Geographic location identification code) - i.e. the location within the context of a geographical coordinate system
• "Address based location identification code" (urn:plcs:rdl:std:Address based location identification code) - i.e. the location within the context of a postal address
• [Product_location_identification_code]
  Error RDL1: The class Product_location_identification_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  - i.e. the location within the context of a product or product version
• "Regional grid location identification code" (urn:plcs:rdl:std:Regional grid location identification code) - i.e. the location at a coordinate within a grid

These are associated with the Location_representation through the use of the template assigning_identification_with_no_organization defined within the capability C001: assigning_identifiers.

Capability templates

The following sections define a set of templates for the capability, where a template is a specification of a set of entities that need to be instantiated to represent a given set of information.

This section specifies the template representing_address_location.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  

Figure 2 —  

Figure 3 —  

This section specifies the template representing_organizational_location.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  Template Configuration for Assigning Organization Location

Figure 2 —  Template Usage

          -- The template assigning_organization_location has an external reference
                     -- organization. Bind this to the local external reference
                     -- Organization. It can now be the target for assignments 
                     %^organization = $assigning_org_location.Organization%
                     -- assign '123456789' to the organization in the role of "DUNS_code"
                     /assigning_identification_with_no_organization(items=^organization, 
                     id='123456789', 
                     id_class_name='DUNS_code',
                     id_ecl_id='urn:plcs:rdl:std')/    

          -- The template assigning_organization_location has an external reference
                     -- org_loc_id. Bind this to the local external reference
                     -- Organizational_location_identification. It can now be the target for assignments 
                     %^org_loc_id = $assigning_organization_location.Organizational_location_identification%
                     -- assign 'DRDL_QGJD' to the location in the role of "Location_identification_code"
                     /assigning_identification_with_no_organization(items=^org_loc_id, 
                     id='DRDL_QGJD', 
                     id_class_name='Location_identification_code',
                     id_ecl_id='urn:plcs:rdl:std')/    

Figure 3 —  Expansion of the instantiation template above

Figure 4 —  Example instantiation of the template

The following characterizations may apply:

Characterization Assigning date

NOTE   this characterization is optional.

Where the representation is defined in the context of an alternative location representation, it is recommended that dates be associated with the main Location for which this is an alternative. However, where specifically required dates can be associated with the Organization_based_location_representation instantiated by the template as shown below.

Figure 5 —  Template Configuration with Optional Calendar Date Assignment.

Note this requires the use of the reference parameter $representing_organizational_location.org_loc_rep to identify the Organization_based_location_representation instantiated by the template representing_organizational_location.

/assigning_calendar_date(items='$representing_organizational_location.org_loc_rep', date_class_name='Date_actual_observation', date_ecl_id='urn:plcs:rdl:std', year='2005', month='05', day='04')/

Characterization Assigning identifiers with no organization

NOTE   this characterization is optional.

• Organizational_based_location_representation -

  An identifier can be associated with the instance of Organizational_based_location_representation by using the template assigning_identification_with_no_organization. Where required an [Organizational_based_location_identification_code]
  Error RDL1: The class Organizational_based_location_identification_code does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  - (i.e. the location within the context of the relevant Organization) can be assigned to an instance of Organization_based_location_representation. This should be done when more than one instance of Organization_based_location_representation is referenced in the context of an alternative location.

• Organizational_location_identification -

  The model allows for a list of [0:?] Organizational_location_identification instances to be created. The template forces one instance of Organizational_location_identification to be created and one instance of identification_assignment to carry the location and identification type. However, because the location identification instance is accessible outside of the template, any number of assignments can be made to the Organizational_location_identification, if required using the template assigning_identification_with_no_organization. This makes creating a separate instance of for each one superfluous. Thus, it is recommended to create only a single Organizational_location_identification for each representation. There may be 1 or many location and identification types assigned using assigning_identification_with_no_organization for each organization represented.

  NOTE    The identifier type should be of class "Organizational location identification code" (urn:plcs:rdl:std:Organizational location identification code).

• Organization -

  Further identifiers can be associated with the instance of Organization by using the template assigning_identification_with_no_organization. This might include additional organization id codes that can be assigned to an instance of Organization, if required (e.g. CAGE Code, UID..). The assignment should be classified as a type of "Organization identification code" (urn:plcs:rdl:std:Organization identification code) or "Organization name" (urn:plcs:rdl:std:Organization name).

This section specifies the template representing_geographical_location.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  Base Template Configuration for Representing Global Location Representation

Figure 2 —  Abstracted Template Configuration for Representing Global Location Representation

Figure 3 —  Template for Representing Global Location Representation

The following classes and their sub-classes can be used:

classifications: [Radian]
Error RDL1: The class Radian does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
[Degree]
Error RDL1: The class Degree does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml

The following classes and their sub-classes can be used:

classifications: [Radian]
Error RDL1: The class Radian does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
[Degree]
Error RDL1: The class Degree does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml

The following classes and their sub-classes can be used:

classifications: [Metre]
Error RDL1: The class Metre does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
[Feet]
Error RDL1: The class Feet does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml

          -- The template representing_geographical_location has an external reference 
                       -- geog_locn. It can now be the target for assignments e.g.
                       %^todays_location = $representing_geographical_location.geog_locn%
                       -- e.g assign 'wilderness' to the global_location_representation in the role of "Geographic_area"
                       /assigning_identification_with_no_organization(items=^geog_locn, 
                       id='Wilderness', 
                       id_class_name='Geographic_area',
                       id_ecl_id='urn:plcs:rdl:std')/    

Figure 4 —  Entities instantiated by representing_geographical_location

Figure 5 —  Entities instantiated by expanding representing_geographical_location

Figure 6 —  Entities instantiated by expanding representing_geographical_location

Figure 7 —  Instantiation of template

The following characterizations may apply:

Characterization Global_location_representation

NOTE   this characterization is optional.

In general no further characterization of the units is permitted. However, the instance of Global_location_representation, may be characterized as described above in the introduction. See Additional Identification details.

The instance of Global_location_representation, may also be (optionally) referenced as a member of alternative location representations from an instance of Location. This may be be illustrated in the figure below by relating the two templates; assigning_location and representing_geographical_location.

Figure 8 —  Instantiation of template

This section specifies the template representing_grid_location.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Figure 1 —  

Figure 2 —  

The following classes and their sub-classes can be used:

classifications: [radian]
Error RDL1: The class radian does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
[degree]
Error RDL1: The class degree does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
[Unknown]
Error RDL1: The class Unknown does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml

coord_val (Type= 'ENTITY (
Error ER1: The entity PLANE_ANGLE_MEASURE does not exist
PLANE_ANGLE_MEASURE)'
Error EXP-1: The EXPRESS entity PLANE_ANGLE_MEASURE
does not exist in data/schemas/ap239_arm_lf.xml.
)

Figure 3 —  

Model reference data

The following classes of reference data are required for this capability:

© OASIS 2010 — All rights reserved