Talk:CATREL
jens 06:36, 27 August 2010 (UTC)
Do we need excluded as well?
raphael 07:05, 27 August 2010 (UTC): If we have "excepted" I think not. Confusion may be my fault, I have probably used "excluded" and "excepted" interchangeably.
jens 09:47, 27 August 2010 (UTC) oops, my fault. I haven't checked the definitions and my translation was tending to German too much :)
Thanks Raphael.
DavidAcland 15:32, 28 September 2010 (UTC): Can we please now come to some decisions? I recommend the Alternative Definition and the Proposed Alternative Remarks, which is not surprising because I think I drafted them. Any other views?
jens 10:28, 7 October 2010 (UTC) copied from Raphael's email sent 4 Oct 2010
About decisions on CATREL: Since we prefer to use roles, CATREL should be deleted as an Attribute and turned into a Role; I can look up the S-100 way of describing Roles and propose a page template for Roles. I am holding back because the final model and wording might depend on TSMAD's reply to our email about roles and named associations.
DavidAcland 09:13, 9 February 2011 (UTC) We now know that, if the S-100 changes proposed by SNPWG and developed at TSMAD21 in Vancouver Island are adopted, our MPA application schema, including CATREL, will not have to change. In order to avoid the "limbo" mentioned by Eivind, I suggest that we continue on the assumption that the S-100 change will be adopted. We will have to report to HSSC that we have made this assumption.
(( Jens's 07:03 post of 11 Feb 2011 post was here. Moved down to foot of string by DA - 09:45 11 Feb 2011))
I am therefore continuing the review of the FCD, on the basis that CATREL replaces LIMTYP. I have further amended the Proposed alternative Remarks, which I think is now simpler and clearer. Can we agree on this and the CATREL definition?
raphael 02:08, 10 February 2011 (UTC): Should "not recommended" (value 2) be taken literally, or interpreted as "discouraged"?
Do we need the remarks at all? I think it is clear without any remarks.
The MPA model does not need to change, but the changes proposed by the TSMAD21 group also allow a model like the diagrams in the proposal we submitted and we can use CATREL there too, so references to a specific object (like APPLIC) should be removed.
DavidAcland 16:42, 10 February 2011 (UTC) Thank you. Good. I will have a go at redrafting the definition. I think of "Not recommended" exactly as "Discouraged". Sometimes SDs say that use of a passage between two islands or banks is "... not recommended ...", say for vessels over a length, or perhaps "in darkness" or "without local knowledge". Some Masters may choose to ignore this advice and use the passage anyway.
"included" (6) and "excepted" (7) are clearly different from values 1 - 5; apples and oranges. I cannot remember why we needed them but a weakness of my 2nd Alternative definition is that they do not fit into this range of ideas. Assuming we do still need them, can we move them to a different attribute? Perhaps with a name something like:
"Membership".
Definition: Defines whether a vessel of the specified characteristics is a member of the group for which the QUARTET item applies.
jens 07:03, 11 February 2011 (UTC) membership sounds good for me. I also agree with the proposed alternative remarks.
My preference would be the 2nd Alternative definition to keep the use of that attribute more open.
DavidAcland 09:48, 11 February 2011 (UTC) Jens, Judging by the placement and content of your post this morning I have assumed, perhaps wrongly, that you have not seen Raphael's post yesterday and my response to it. Please therefore confirm that you do wish to retain the 2nd alternative Remarks rather than removing them as suggested by Raphael.
I will tidy up where I think we are agreed and draft Membership.
jens 10:41, 11 February 2011 (UTC) I have seen your's and Raphael's discussion. Removing the remarks might be sufficient. Particularly seeing the 2nd definition alternative it keeps the use more general.
Anyhow, I believe it is worth being mentioned for what this attribute is supposed to be. The only amendment I suggest is to add intentionally to "APPLICABILTY, to which this attribute is intentionally bound, e..." What do you think?
jens 10:57, 11 February 2011 (UTC)minor question. Should "when" replaced by "if" at the alternative remark entry?
DavidAcland OK.
In binding we are talking about the Product Specification, so it is hard to imagine a binding which is unintentional. So I think changing "When " to "If" takes account of your "intentionally" suggestion.
I prefer to keep the Remarks; not least because it helps me remember how we were planning to use the features and attributes. When the time comes, we can probably remove them to a "Use of the Object Catalogue" and they will serve as an initial guideline.
jens 11:16, 11 February 2011 (UTC) I knew it, David, I knew it. You would find a way. lol
raphael 21:17, 11 February 2011 (UTC): In the new Remarks: "...it expresses the relationship to another feature" seems more accurate (if bound to APPLIC, it expresses the relationship of the set of vessels described by APPLIC to, say, REGLTS).
The other changes are fine.
jens 10:52, 16 February 2011 (UTC) proposed alternative definitions. I guess the current versions limit the use of the terms.
raphael 18:38, 16 February 2011 (UTC): I think the dictionary definitions are too general for nautical information. If it is necessary to change the definitions, how about formulating them like this:
prohibited: use of facility, waterway, or service is forbidden
jens 08:15, 18 February 2011 (UTC) My intention was to widen up the use of those values. I understand that it is quite general. Your (Raphael's) proposal makes sense in a way to make the values multiple usable and keep the marine context. I suggest to reword the definitions according to Raphael's proposal.
DavidAcland 16:39, 21 February 2011 (UTC) Agreed. I will make the changes. Do you (Jens) want to withdraw your alternatives?
jens 18:23, 21 February 2011 (UTC) yes, I will.
raphael 18:08, 28 February 2011 (UTC): We need a new page for "Membership" defined in David's post of 10 February above.
There is the question of which class or classes "Membership" should be bound to. In the new TSMAD general feature Model, associations can have attributes, which is generally what was requested in our proposal to TSMAD. We can make an association class with one attribute (Membership), and another association class for the CATREL attribute. Alternatively, we make one association class with 2 attributes Membership and CATREL and define a constraint that only one of CATREL or Membership can have a value. I think the first leads to a cleaner model, but am open to arguments against.)
Background: In UML an association class, being an association as well as a class, can associate only one set of classes (that is, we cannot have A<---AppliesTo--->B as well as P<---AppliesTo--->Q unless A is a generalisation of P, and B is a generalisation of Q.)
We could also think about using abstract classes. That is, make an abstract class (AbstractRelationship?) which has subclasses X1 (attribute CATREL) and X2 (attribute Membership).
I also think an abstract class which generalises the Quartet would be useful (AbstractRXNClass?). The quartet classes always seem to go together in the UML diagrams, and a single stand-in for all 4 of them would be convenient. Also, it means we do not need to define a different association class for each of the 4 Applicability/(QUARTETCLASS) associations (ref. the Background note above).
raphael 21:15, 28 February 2011 (UTC): This diagram illustrates the ideas. AbstractRXNClass is a generalisation of the quartet; "AppliesTo" is an association class linking it to Applicability.
jens 18:47, 1 March 2011 (UTC) I hope to understand and will try to explain with my own words to ensure that I understand the new idea correctly.
We have got a feature (anchorage). Certain quartet information applies to that area. Some information is useful for one vessel and excludes another, vice versa. We need to introduce MBRSHP as named association class to set up the link between APPLIC and the quartet correctly.
Further we need to have a set of attributes or named associations to explain
- the degree of completeness of the information (to decide and likely to develop);
- the issuing authority CATAUT;
- the information to what the quartet information pertains CATRXN and
- the relationship CATREL
and how to store the quartet information (which is actually a file name stored at TXTDSC) computer friendly.
Raphael's proposal is to combine CATRXN and CATAUT somehow to a generalised AbstractRXNClass?). David was saying 15:40, 1 March 2011 (UTC) that actually similarities are difficult to identify between CATRXN and CATAUT and suggest to postpone the decission.
We are trying to figure out how to cut the Gordian knot. Am I correct?
raphael 08:03, 2 March 2011 (UTC): I'll explain by copying and editing the first part of Jens' post:
We have got a feature (anchorage). Certain quartet information applies to that area. Some information is useful for one vessel and excludes another, and vice versa. We need to introduce association class AppliesTo (with attribute MBRSHP) as a named association class to set up the link between APPLIC and the quartet correctly.
Further we need to have a set of attributes of the Quartet object to explain:
- the degree of completeness of the information (to be decided and likely to develop);
- the issuing authority CATAUT;
- the information to what the quartet information pertains CATRXN
Similarly, to explain whether use of a geographic feature or service is required, recommended, etc., we need to introduce another association class X (with attribute CATREL) as a named association class to set up the link between APPLIC and the object or service correctly. (E.g., PILBOP<---X--->APPLIC).
(Because it is moved to the association class X, CATREL is no longer an attriute of APPLIC.)
(End of edit.)
UML won't allow us to have both REGLTS<---AppliesTo--->APPLIC and RCMDTS<---AppliesTo--->APPLIC in the same model. The solution is to make the association to a superclass of REGLTS and RCMDTS - hence, AbstractRXNClass.
Combining CATRXN / CATAUT is a different issue, which would affect this diagram only by changing an attribute or two of the Quartet or their new superclass AbstractRXNClass.
jens 12:30, 2 March 2011 (UTC) Thanks Raphael. I hope I got it.
PILBOP<---association class X with attribute CATREL--->APPLIC<---AppliesTo--->superclass(AbstractRXNClass)
My remaining questions are how to involve 0..n of the quartet in the model? How are they linked to superclass(AbstractRXNClass) or are they part of superclass(AbstractRXNClass) now?
raphael 05:06, 3 March 2011 (UTC): The quartet are subclasses (that is, UML specializations) of AbstractRXNClass, so they inherit the associations, attributes, and multiplicities of AbstractRXNClass unless explicitly overridden, which is not the case here. (For 0..n, change 1..* at the AbstractRXNClass end of the APPLIC---AbstractRXNClass association to 0..*.)
raphael (talk) 04:19, 18 January 2017 (CET): Since the definition has been questioned, here are some alternative definitions:
- Expresses the level of insistence for or against an action or activity.
- Expresses constraints or requirements on vessel actions or activities in relation to a geographic feature, facility, or service.
jens (talk) 07:01, 23 January 2017 (CET) I prefer the second alternative.