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 Regulations (or Recommendations, 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.

Textual Regulations and Notes

(Source - S-131 Edition 1.0.0 DCEG)

Use of appropriate information type

The appropriate information type from Regulations, Restrictions, Recommendations, and NauticalInformation should be used depending on the nature of information to be encoded.

1. Regulations is intended to be used for official rules, laws, and similar source material, i.e., sources that have the force of law or are mandated by a controlling authority. They will generally originate from some kind of administration or authority, including port authorities.
2. Restrictions is intended for restrictions that constrain the activities of vessels temporarily with or without the legal force, or for longer terms without the force of law; they may be issued by a local authority such as a port captain or US Coast Guard district.
3. Recommendations is intended for encoding suggestions, limitations, or preferred procedures that are not mandatory.
4. NauticalInformation is intended for material that is largely informative in nature, of which does not fit into the category of regulation, recommendation, or restriction.

Content

The content of the regulation (or recommendation, restriction, or note) should be encoded using the textContent attribute. Text content should be compact and accessible to the expected audience, and include pertinent information, in summary form if necessary. Generally, avoid including the entire text of regulations where it is complex in structure or unncessarily legalistic or verbose. Instead, condense long regulations or notes into a summary, include exceptions not covered by the summary, and include a reference where the full details can be obtained. References should be accessible to mariners, so they can obtain the complete text.

Textual content may be supplemented by one or more diagrams or sketches using the graphic attribute.

Classification

The classification attributes categoryOfRxN and actionOrActivity codelists in the rxnCode complex attribute should be populated wherever possible, in order to facilitate mariner identification of information relevant to particular route planning or navigation tasks.

1. Being open enumeration codelists, these attributes allow for additional categories not listed among their standard values. For example, an “under repair” activity might be encoded in the actionOrActivity attribute (as “other: underRepair”).
2. Note that such extra values will merely be displayed and not processed (for example, the user interface will not use extra values to choose symbols or filter instances of Regulations, whereas it may apply filters to the standard values and/or them in portrayal).

Titles and headlines

The headline attribute of rxNCode should be used to encode brief topic headings describing the textual content of the Regulations object. Topic headings in the source material may be suitable either as-is or being adapted for use in the intended application context (for example, being shortened for readability on an ECDIS screen or auxiliary display).

1. The headline attribute of the textContent/information attribute may also be used to provide sub-heads but must not duplicate the content of rxNCode/headline.
2. Where multiple headline attributes are encoded in the same instance of rxNCode complex attribute, they must be ordered as follows:
   1. If the headline values are derived from a source material (such as the published legal text of a government regulation), the ordering must conform to the hierarchy in the source, for example, section headings must precede sub-section headings. It is not necessary to include the entire hierarchy of headings for the portion that is actually encoded in the textContent co-attribute.
   2. If the headline values are not derived from a source text, the ordering should be from general to specific.

Schedules

Operating schedules and business hours of organizations are encoded by associating a ServiceHours instance to an Authority. Partial work schedules on holidays or other special days are encoded by associating a NonstandardWorkingDay instance to the ServiceHours instance.

Similarly, operating schedules for a facility are encoded by associating a ServiceHours to the geographic feature instance representing the facility, and associating a NonstandardWorkingDay to the ServiceHours to encode partial working days.

To encode 26-hour operation, omit the times of day. Alternatively, midnight to midnight can be encoded (00:00:00 to 24:00:00).

Seasonal variations in service hours can be encoded using multiple Service Hours instances with appropriate periodicDateRange values.

If the schedule is complex, it may help to put in tabular form before attempting to encode it. The following tabular structure is suggested - encoders may adapt it as convenient.

Normal operations
Operations	Days	Time	Notes
Normal / closed / unmanned / other: ...	(Days of week)	(Times of day)	(additional information)
Normal	Mon	11:00 to 15:00	Banker's hours every Monday
Normal	Tue - Thu	05:00 to 17:00	(info for encoder - when dayOfWeekIsRange = true)
Normal	Fri, Sun	06:00 to 10:00	(info for encoder - when dayOfWeekIsRange = false)
...	...	...	...
Exceptions
	days of exceptional schedules (fixed and floating public holidays, etc.)		(information about operation on specified special day)
	...		...

Simpler schedules may be expressible in phrases:

• Normal operation: (date range) DoW-DoW, hh:mm-hh:mm, (additional information/link)
• Exceptions: (fixed/variable dates), (additional information/link)

The S-131 DCEG contains an example, similar to the example below:

ServiceHours

scheduleByDayOfWeek

categoryOfSchedule =1 (normal operation)

timeIntervalsByDayofWeek

dayOfWeek =2(Monday), 4(Wednesday)

dayOfWeekIsRange =0 (false)

timeIntervalsByDayofWeek

dayOfWeek =5(Thursday), 7(Saturday)

dayOfWeekIsRange =1 (true)

timeOfDayStart = 08:00:00

timeOfDayEnd = 16:00:00

NonStandardWorkingDay

dateFixed = (December 26) as <gMonthDay>--12-26</gMonthDay>

dateVariable = "Last Monday in May" (without quotes)

information.text = “By pre-arrangement” (without quotes)

Interpretation: A service is available under normal operation status 24 hours/day on Monday and Wednesday, and from 08:00 to 16:00 LT from Thursday to Saturday. The service is available by pre-arrangement on the last Monday in May and the 26th of December of each year when they fall on days which would otherwise be normal working days.