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."

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.