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.
jens 04:57, 24 August 2009 (UTC)
Two new attributes proposed by Raphael
LIMTYP to be found at FDD page now
CATRGY to be found at FDD page now