S-131 MHI Best Practices

Limitation by Vessels Characteristics and Cargo

(Source - S-131 Edition 1.0.0 DCEG)

Capturing the application of a regulation, recommendation, etc. to specified kinds of vessels

This will generally be modeled by an InclusionType relationship between the abstract supertype AbstractRxN (as the superclass for Regulations, Restrictions, Recommendations, and NauticalInformation information type classes) and the Applicability class.

Encoders may find it easiest to capture the application of a regulation (recommendation , etc.) to a class or set of vessels in three phases:

1. Encode the operative part of the regulation (the part that describes what the vessels subject to the regulation must or must not do), creating an instance of Regulation (or Recommendation, etc., as appropriate). Descriptions of what kinds of vessels are subject to the regulation must be excluded from the content of the Regulation instance.
2. Create an Applicability information type and encode the description of what kinds of vessels are subject to (or exempted from) the regulation.
3. Link the two using an InclusionType with membership=included if the vessels described by Applicability are subject to the regulation, or membership=excluded if they are explicitly exempted from the regulation.

It is not necessary to create separate instances of the regulation for inclusion and exclusion.

Capturing the permissibility or otherwise of a geographic feature for specified kinds of vessels

Encoders may find it easiest to capture the permissibility of a feature to specified kinds of vessels in three phases.

1. Create the geographic feature if it does not already exist.
2. Create an Applicability information type and encode the description of what kinds of vessels are required to use the geographic feature.
3. Link the two using a PemissionType with categoryOfRelationship = required.

For the other relationships (prohibited, not recommended, etc.) steps 2 and 3 should be modified accordingly (i.e., if use by certain kinds of vessels is “not recommended” encode the description of that kind of vessels in an Applicability and create a linking PermissionType with categoryOfRelationship = not recommended). It is not necessary to create a separate instance of the geographic feature for each type of relationship.

Constructing the Applicability information type

Where the source material describes complex conditions, encoders may find it useful to write out the conditions in structured language with grouping parentheses, for example, as “(condition A) AND (condition B) AND (condition C)”, or draw diagrams, before encoding Applicability and its associations.

Note that the model limitation on mixing logical connectives means some forms of conditions which use “nesting” cannot be encoded in a single Applicability instance and multiple instances must be created.

EXAMPLE: The complex condition “(condition A) AND ((condition B) OR (condition C))” must be encoded as two Applicability instances, one with “(condition A) AND (condition B)” and the other with “(condition A) AND (condition C)”.

Example of conversion of complex condition to multiple simple conditions

Complex condition	Encode as
(condition A) AND ((condition B) OR (condition C))	Applicability 1: (condition A) AND (condition B) Applicability 2: (condition A) AND (condition C)

Data producers may contact NIPWG with questions about encoding complex conditions.

As a last resort, conditions may be written as phrases in natural language and encoded in the information attribute. It is acceptable for an Applicability to have only the information attribute populated.