Talk:CHALIM

jens 17:19, 21 December 2008 (CET)

Initially I added CATREA; works together with RESTRN describing RESARE features and completes this data structure.

I though deeper of these two attributes. I don't see why to use them. If restrictions like these apply the RESARE geometry can be used. That makes the duplication of these attributes superfluous. They are described there.

Remarks shown in brackets are doubtful. That makes in my opinion not much sense.

DavidAcland 16:28, 15 January 2009 (CET)

I came to the same view independantly. I do not see the need for CATREA nor how to use it,if it were retained. I believe resdes will cover restrictions better than RESTRN. Both deleted.

Agree that bracketted remarks can go. Deleted and copied in here for the record:

((((RESTRN and CATREA encode the type of restriction; a short explanation may be given by the use of the attributes INFORM, and NINFORM.))))

DavidAcland 17:26, 19 January 2009 (CET)

Now that we have the attributes agreed, it is worth thinking again about the logic.

1. Most attributes indicate the limits for passage or use of a facility or area.

2. prfmnc is a bit different because as drafted it states what is required. Perhaps we could amend that to read "minimum requirement" for "hull design, main and auxiliary machinery etc".

3. The real problem is the 3 brothers. The definition mentions "...restrictions...". Accepting that we are currently building the data dictionary and not the product specification, and that the binding shown here is only our feeling for the way attributes could be combined in a product, do we need rcmdts and reglts? What I am really getting to is, if the restrictions are fully covered by the attributes, could we remove resdes as well? If we could, that would remove one of our cases where we have an association between info objects.

4. If we do want to keep rcmdts and reglts, we should probably include these ideas in the final phrase of the definition, along the lines "...and an indication of the recommendations, regulations, and restrictions that apply."

DavidAcland 17:50, 21 January 2009 (CET) This used to be restvc

jens 19:09, 21 January 2009 (CET) Make sense. I haven't got objections.

Raphael This object may need a little more clarification about where it should and should not be used. It is tempting to use it everywhere one wants to encode information that depends on vessel characteristics, e.g., compulsory pilotage requirements.

How would "AND" clauses be expressed? For example "single hull tank barge carrying 5000 or more barrels of oil or other hazardous material". Relatedly, if limitations are expressed in terms of both AND and OR clauses, then we may have problems. (A hypothetical example would be "oil tankers carrying more than 10000 barrels, or single hull tank barges carrying more than 5000 barrels of oil". I don't know of such a limitation, but perhaps something like it might be in force somewhere? raphael 07:07, 23 March 2009 (CET)

Update: From the discussion below it appears "AND" combinations are not covered by the coded attributes, and such "AND" combinations would have to be in plain text in the INFORM or TXTDSC of the associated resdes/rcmdts/reglts object?

Also, are capacity bounds expressed in terms of "barrels" needed? raphael 07:44, 23 March 2009 (CET)

jens 19:54, 24 March 2009 (CET)

Raphael, thanks for your comments made. I was not in the office today so I apologize for not having replied earlier. I will try to develop an answer for the first topic tomorrow. (including your update comments)

Regarding the second topic I have in mind, that the "barrel" problems was addressed to TSMAD who should be responsible for the several UNIT attributes. A paper addressing this problem was passed to them. We awaiting their response in due time.

3 brothers in relationship to this object

I hoped that would be quite simple, but...

What was our intention with this object? We intended to cover ALL limitations (restrictions, regulation, recommendations). That is probably too much. I checked this object against the other information objects. All (nearly all) have the DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as type A attribute. (by the way, I think we should add those where they are not been added yet)

I thought that was the key to solve the problem. In a first view I recommended to put DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA to restvc and to delete the three brothers. We can handle the relationship between the geo object (where the limitations apply) and the restrictions of vessels and well as our three (four if we add nautical information) brothers. That would work fine anyway and I really recommend to do it.

Adhering to this, we will have one major problem. How to handle different limitations and brothers for different types of vessels for the same geo object? One way, the easiest for us, is to continue our initial idea to add inf object to inf objects. The other idea is to handle the reference within the geo object by using ...I don't know. INFORM - bad. Within the written text of the brothers - I'm not convinced that it works. Where else?

To summarise my ideas, the only one which solves all problems is to continue with inf object to inf object and to improve the definition in a way that "restrictions" will not be shown. Independently from that we should add DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as well to make the "normal" handling convenient to the modeller.

David, what do you think? My mind (the German and the English one) is at the death end.

DavidAcland 18:41, 20 January 2009 (CET) OK. I will try it. In any case we are not likely to have lots of combinations of vessel type, cargo types and say length. In many cases we will only have one characteristic in play, say, draught, breadth or cargo. Similarly there may be recommendations for vessels over a particular length of all type of vessel or cargo.

So if we want to widen this beyond "restrictions" to all 3 or 4 brothers, this sounds a bit like "cause and effect"; i.e. "With this condition, this is the impact - result - advice - outcome ..." Of these I prefer "impact" in the way that we write "impact assessments" to indicate the likely effect of a course of action. So this could give us an object called "Impact of vessel characteristics". I will mull this over a bit more and work on a tweek to the definition along these lines.

Talking to Mal tomorrow, 21 Jan, about the value or otherwise of nautinf and to Barry about Info-Obj to Info-Obj associations. Brgds, David

DavidAcland 11:01, 21 January 2009 (CET)

Discussed with Mal.

We concluded that we should build on your idea of "limitations". This is much better than impact and very similar in meaning to "restrictions" but it is a different word and therefore should prevent confusion and ease the semantics. We also think that we should remove the final clause of the defintion, "... and an indication of what restrictions apply."; just leave it blank. It goes without saying that the associated Info objects amplify the origianl information.

We think that natinf should be added to the 3 brothers more or less everywhere. This would allow for the neutral case, where information is provided for the Master to take into account in relation to the current plan being developed or executed.

Met Barry.

What we are doing is fine and is already catered for in the model. We are effectively using a Master/slave relationship, even between Info Objs. As I now understand it, the problem would have been with some other type of "named relationship".

Asked Barry about NOBJNM and OBJNAM on Info Objs. He said that that was fine. In the case of Regulations this is likely to be the name of the Act of Parliament, (i.e. Marine Bill 2007), national regulation, or the Harbour Regulation. These would probably not be populated in the case of natinf, which is likely to be a reported fact.

Redrafted along these lines.

Replaced the following remarks:

This object is used to describe the conditions under which restrictions apply to vessels in a specified area. Restrictions apply to vessels which:

• match one of the values in the ship type attribute;

• exceed the value of one of the “max” attributes or;

• do not meet one of the “min” attributes.

As an example of how this object could be used, ship dimensions or type of cargo could be used in combination with a specified area in which regulations (e.g. length limit or type of cargo restrictions) apply.

jens 13:10, 21 January 2009 (CET) As I always knew, three minds create more thoughts than one. Thanks for your investigations and Mal's and Barry's feedback. I think we got it. I see that there is a way to handle the relationship between different inf object by using OBJNAM and with the geo object by master slave . I my opinion it looks fine now. If you will agree I will follow you soonest.

DavidAcland 14:15, 21 January 2009 (CET)

Good. I have unticked your approval on all 4 brothers because I have made several edits to each in line with this discussion.

Proposed attribute LimitationType

raphael 22:15, 7 August 2009 (UTC) : A new attribute Limitation Type is proposed. This attribute is intended to expand the expressiveness of CHALIM by allowing a more precise machine-readable specification of what is meant when a CHALIM is associated with some other object, for example 'negative limitations'. For example, to encode a limitation that applies only to vessels of draught greater than 12m, use LIMTYP=10 (included), MAXDRF=12; to encode a limitation that does not apply to vessels of draft greater than 12m, use LIMTYP=11 (excepted), MAXDRF=12. To encode a limitation that applies only at night, use LIMTYP=14 (new code meaning "applicable at night").

Concerning the enumeration: The first 4 (prohibited, required, permitted, recommended) are intended for use when CHALIM is attached to a facility to capture the fact that it is intended for use by vessels meeting certain limitations. The other two (included, excepted) are intended for use with regulations, etc.

Comments are invited, including amendments and extensions to the listed values.

Attribute: Limitation type

Acronym: LIMTYP

Attribute type: Simple

Camel case: limitationType

Data Type: Enumeration

Definition: This attribute describes the interpretation of a “chalim” information object in the context of the object(s) with which it is associated.

Values:

ID Meaning Definition

1: prohibited

2: required

3: permitted

4: recommended

10: included

11: excepted

Definitions:

prohibited

use of facility (boarding place, etc.) by vessels satisfying the conditions is prohibited

required

use of facility (boarding place, etc.) by vessels satisfying the conditions is required

permitted

use of facility (boarding place, etc.) by vessels satisfying the conditions is permitted but not required

recommended

use of facility (boarding place, etc.) by vessels satisfying the conditions is recommended

included

associated information object applies to vessels satisfying the conditions

excepted

associated information object does not apply to vessels satisfying the conditions

Remarks: The conditions under which the limitation operates are those expressed by the “chalim” object to which this attribute is bound.

Proposed attribute Category of Registry

raphael 06:28, 11 August 2009 (UTC) : A new attribute Category of Registry is proposed. This attribute is intended to allow distinguishing between vessels registered under the same national flag as the port etc., to which some information is attached, and vessels registered under a foreign flag. The third category was added to cover all the possibilities - consideration of the need for it will be appreciated. As usual, comments invited.

This attribute is proposed to be bound to CHALIM.

Attribute: Category of vessel registry

Acronym: CATRGY

Attribute type: Simple

Camel case: categoryRegistry

Data Type: Enumeration

Definition: The locality of vessel registration or enrolment relative to the nationality of a port, territorial sea, administrative area, exclusive zone or other location.

Values:

ID Meaning Definition

1: domestic

2: foreign

3: both domestic and foreign

Definitions:

domestic

The vessel is registered or enrolled under the same national flag as the port, harbour, territorial sea, exclusive economic zone, or administrative area in which the object that possesses this attribute applies or is located.

foreign

The vessel is registered or enrolled under a national flag different from the port, harbour, territorial sea, exclusive economic zone, or other administrative area which the object that possesses this attribute applies or is located.

both domestic and foreign

The vessel is registered or enrolled under more than one flag, one of which is the same as that of the port, harbour, territorial sea, exclusive economic zone, or other administrative area which the object that possesses this attribute applies or is located.

Remarks: No remarks.