Capability (C049):— assigning

The purpose of this capability is to enable the asignment of a Location to an entity of interest such as a Product_as_realized, Activity, Required_resource, or Event. Clearly for a product that moves, such as a ship, there are an infinite number of locations that it would have been in. The purpose of the capability is to enable the assignment of the Location when a significant event occurred such as a maintenance task, or a failure state occurred.

Information model overview

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

General

A Location_assignment is a relationship between a Product, Event, or Person and a Location. There may be a distinct assignment for each qualification. For example planned, scheduled or actual locations.

Each assignment may have a start and end date or time. A Location may have multiple Location_assignments. The information model for assigning location is illustrated below.

The EXPRESS-G for assigning location is shown in Figure 1. below and explained in the following sections.

Location

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 such as;

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), e.g.;

The items to which a Location_assignment can be assigned is determined by the select type (location_assignment_select), which varies depending upon the DEX in which this capability is used.

Alternates

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.

Relationships

The following sub-classes of "Location relationship role" (urn:plcs:rdl:std:Location relationship role) are provided for use with this DEX, but may be specialised where required by business-specific requirements;

NOTE There is no restriction on the types of relationship, however, the use of an alternative relationship should be used with care to ensure that the location related is indeed an alternate location and not an alternative representation of the relating location. For this purpose the alternative_location_representations of a Location should be used.

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.

Characterization: Assigning approvals (Optional)

The Approval and Approval_assignment are classified as a [Location_approval]

Error RDL1: The class Location_approval does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, or other suitable sub-class of [Approval_purpose]

Error RDL1: The class Approval_purpose does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and [Approval_assignment_role]

Error RDL1: The class Approval_assignment_role does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, respectively. (Note classification and reference data is described in C010: assigning_reference_data).

The Approval represented will have a status associated with it indicating whether the assignment has been approved or not. See C019: assigning_approvals for details on assigning approvals.

Characterization: Assigning Dates (Optional)

Characterization: Assigning a Person or Organization (Optional)

Characterization: Assigning Effectivity (Optional)

Care needs to be taken using Effectivity if also using planned start and planned end dates assigned directly to the Location_assignment, to avoid a conflict of semantics. Where there are multiple or overlapping periods when a location may be effective, then assigning_dated_effectivity should be used to manage them. However, for exchanging simple cases or where effectivity is not within the scope of the schema, then it is recommended to use assigning_calendar_date as described above and in capability C036: assigning_date_time.

Characterization: Assigning Property (Optional)

NOTE For the example above, the maximum draft may be represented as a property of the shipyard, when the yard is being treated as a resource.

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.

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

This template describes the assignment of a location to an entity_for_location.

The following input parameters are defined for this template:

The following reference parameters are defined for this template:

For example, to identify the name of a location by assigning an identification to the Location entity. E.g.

              -- The template assigning_location has an external reference
              -- location. Bind this to the local external reference
              -- Location. It can now be the target for assignments 
              %^location = $representing_location.location%
              -- assign 'Home' to the location in the role of "Name"
              -- as known by organisation with the name "Company_name".
              /assigning_identification(items=^location, 
              id='Home', 
              id_class_name='Name',
              id_ecl_id='urn:plcs:rdl:std'
              org_id='Company_name'
              org_id_class_name='Organization_name'
              org_id_ecl_id='urn:plcs:rdl:std')/

The instantiation path shown below specifies the entities that are to be instantiated by the template.

A description of templates and the syntax for the instantiation path is provided in the Reading Capability Templates help section.

-- Mark the Location entity as
-- referable when this template is used by binding it to the reference
-- parameter location
%^location = Location%
Location.description = '/IGNORE'
Location.name = '/IGNORE'

-- If the optional alt loc rep is provided then link to Location
Location.alternative_location_representations -> @alt_locn_rep

-- assign an identifier and classify it with input params
/assigning_identification(
    items=^location,
    id=@loc_id,
    id_class_name=@loc_id_class_name,
    id_ecl_id=@loc_id_ecl_id,
    org_id=@loc_org_id,
    org_id_class_name=@loc_org_id_class_name,
    org_id_ecl_id=@loc_org_id_ecl_id )/

-- Mark the location_assignment entity as
-- referable when this template is used by binding it to the reference
-- parameter id_assgn
%^locn_asst = Location_assignment%
Location_assignment.description = '/IGNORE'
Location_assignment.role = '/IGNORE'
Location_assignment.location_for_assignment -> ^location
Location_assignment.entity_for_location -> @entity_for_location

-- provide the role of the identification by classifying the location_assignment
/assigning_reference_data(
    items=^locn_asst,
    class_name=@la_class_name,
    ecl_id=@la_ecl_id)/

The following entities are instantiated with attributes as specified:

Entity in path	Value	Inherited from
Location.description	'/IGNORE'	—
Location.name	'/IGNORE'	—
Location_assignment.description	'/IGNORE'	—
Location_assignment.role	'/IGNORE'	—

The following section details how the assigning_location template can be optionally characterized by assigning other constructs to it. These are characterizations commonly applied to the template. The ISO 10303-239 EXPRESS model may enable other assignments to the entities instantiated by the template.

The following characterizations may apply:

Characterization Assigning date

NOTE this characterization is optional.

Dates can be associated with the assignment of a location_assignment by using the template assigning_calendar_date. For example, the planned start and end date of a location assigned to an instance of Location_assignment.

Figure 5 — Template Configuration with Optional Calendar Date Assignment.

When instantiating the templates for assigning a date to a referenced location_assignment this requires the use of the reference parameter $assigning_location.locn_asst to identify the assigning_location instantiated by the template Location_assignment).

Characterization Assigning reference data

NOTE this characterization is optional.

Reference data can be associated with the location instance by using the template assigning_reference_data. For example, the type of location may be assigned to an instance of Location.

Figure 6 — Template Configuration with Optional Calendar Date, Reference Data and Identification Assignment

Care needs to be taken to avoid potential conflicts with the (optional - [0:?]) alternative_location_representations attribute as the subtypes of Location_representation provide the major typing mechanism for this part of the model. Also note that these subtypes are handled in a separate set of templates.

NOTE The mechanism for assigning reference data to a location is shown in figure Figure 6.

Characterization Assigning identifiers

NOTE this characterization is optional.

Further Identifiers can be associated with an instance of location_assignment by using the template assigning_identification. For example, an id may be assigned to an instance of Location_assignment, if required.

NOTE The mechanism for assigning identifier is shown in figure Figure 6.

Characterization Location Relationships

NOTE this characterization is optional.

Two Locations can be associated together by a Location_relationship with the relationship classified appropriately to describe the role (or purpose) of the relationship. This can be achieved by using the templates assigning_location and assigning_reference_data. There may be two assigning_location templates used, which create different Locations for one (or more) entities (e.g. activity). The relationship is classified as a type of "Location relationship role" (urn:plcs:rdl:std:Location relationship role) (or sub-class, e.g. "Alternative location" (urn:plcs:rdl:std:Alternative location)) using the assigning_reference_data template. This is shown in the figure below.