Talk:VSLMSM - Revision history

Rmm at 00:32, 18 July 2018

2018-07-18T00:32:08Z

New page

[[User:DavidAcland|DavidAcland]] 11:10, 5 October 2010 (UTC) I have added a "Units" attribute [[VSLUNT]].
I have also changed the multiplicity of the sub-attributes [[VSLCAR]] and [[VSLVAL]] to make them mandatory. 
Multiplicity of [[VSLUNT]] is also 1 at the moment but see my post on 5 Oct at [[Talk:VSLCAR]]. I think we can only have a maximum of 2 [[COMPOP]] s so I have changed the multiplicity here to 0..2 Does this now work?

[[User:Rmm|raphael]] 03:28, 8 October 2010 (UTC): I don't see why the number of COMPOPs should be limited to 2, each COMPOP compares the specified characteristic from own ship data to the VSLVAL with which the COMPOP is associated.

Actually the table of sub-attributes on [[VSLMSM]] as it is today (07 October 2010) should be changed to have either:
* multiplicity = 1 and sequential = "n/a" for all rows; and we allow [[VSLMSM]] itself to be repeated; or
* multiplicity = 1..* and sequential = "true" for all rows, and we don't allow VSLMSM to be repeated.

The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).

[[User:Jens|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]

[[User:Jens|jens]] 17:26, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). 
Let's try to explain it with an example: Saying example 5 which is to model 
tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP

Using your case 1 I have to model 
PILBOP it the feature 
APPLIC is the associated information object 
LIMTYP 2 (required) 
LOGCON 1 (and) 
CATVSL=3 (tanker) 
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=50; VSLUNT=1 (m) COMPOP= 1 (>)] 
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=100; VSLUNT=1 (m) COMPOP= 3 (<)] 

Using your case 2 I have to model 
PILBOP is the feature 
APPLIC is the associated information object 
LIMTYP 2 (required) 
LOGCON 1 (and) 
CATVSL=3 (tanker) 
#VSLMSM [VSLCAR=10 (L.O.A.); VSLVAL=50; VSLUNT=1 (m); COMPOP=1 (>)], [VSLCAR=10 (L.O.A.); VSLVAL=100; VSLUNT=1 (m); COMPOP=3 (<)]

If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for 
vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. What do you think?

[[User:Rmm|raphael]] 18:29, 13 October 2010 (UTC): OK; both work (in the sense that both allow correct modeling), so if David also prefers option 2, we can agree on that.

[[User:DavidAcland|DavidAcland]] 15:18, 5 November 2010 (UTC): I see good thoughts since I was last here. I see now that multiplicity of COMPOP being 0..2 is wrong.
I think the answer to Raphael's two options posted on 8 Oct is indicated in an example where we have more than one condition; say length and draught as at [[Talk:LOGCON]]. This is getting complicated and I think we need the simplest implementation we can go for. So I favour "exactly one condition" as at Option 1 above and I believe we will need to be able to repeat VLSMSM. I have changed the multiplicity of COMPOP to 1 and everything to Sequential = n/a so that we are coherent with Raphael's advice for Option 1. If Jens warms us to Option 2 we can revisit.

[[User:Jens|jens]] 11:12, 8 November 2010 (UTC) Actually I don't see any need for revising again. We should go ahead with option 1 and see how it works. I only tried to model how it is written in NPs now: "... applies for vessels of 100 m in length or more or 15 m in beam or more or 10 m in draught or more". I have got no stomachache saying: "applies for
 Vessels of 100 m in length or more
 Vessels of 15 m in beam or more
 Vessels of 10 m in draught or more."
 Thus I accepted the attribute and the proposed option 1 for [[COMPOP]] multiplicity and the ProdSpec.

[[User:Rmm|raphael]] ([[User talk:Rmm|talk]]) 02:32, 18 July 2018 (CEST): "Multitude of" in the definition is an "editorial comment" and does not contribute to the definition. Suggest removing it. The definition should be only "Terms and definitions specifically related to vessels.". (Also, a more descriptive definition can probably be devised...)

Jens at 11:12, 8 November 2010

2010-11-08T11:12:25Z

New page

[[User:DavidAcland|DavidAcland]] 11:10, 5 October 2010 (UTC) I have added a "Units" attribute [[VSLUNT]].
I have also changed the multiplicity of the sub-attributes [[VSLCAR]] and [[VSLVAL]] to make them mandatory. 
Multiplicity of [[VSLUNT]] is also 1 at the moment but see my post on 5 Oct at [[Talk:VSLCAR]]. I think we can only have a maximum of 2 [[COMPOP]] s so I have changed the multiplicity here to 0..2 Does this now work?

[[User:Rmm|raphael]] 03:28, 8 October 2010 (UTC): I don't see why the number of COMPOPs should be limited to 2, each COMPOP compares the specified characteristic from own ship data to the VSLVAL with which the COMPOP is associated.

Actually the table of sub-attributes on [[VSLMSM]] as it is today (07 October 2010) should be changed to have either:
* multiplicity = 1 and sequential = "n/a" for all rows; and we allow [[VSLMSM]] itself to be repeated; or
* multiplicity = 1..* and sequential = "true" for all rows, and we don't allow VSLMSM to be repeated.

The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).

[[User:Jens|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]

[[User:Jens|jens]] 17:26, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). 
Let's try to explain it with an example: Saying example 5 which is to model 
tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP

Using your case 1 I have to model 
PILBOP it the feature 
APPLIC is the associated information object 
LIMTYP 2 (required) 
LOGCON 1 (and) 
CATVSL=3 (tanker) 
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=50; VSLUNT=1 (m) COMPOP= 1 (>)] 
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=100; VSLUNT=1 (m) COMPOP= 3 (<)] 

Using your case 2 I have to model 
PILBOP is the feature 
APPLIC is the associated information object 
LIMTYP 2 (required) 
LOGCON 1 (and) 
CATVSL=3 (tanker) 
#VSLMSM [VSLCAR=10 (L.O.A.); VSLVAL=50; VSLUNT=1 (m); COMPOP=1 (>)], [VSLCAR=10 (L.O.A.); VSLVAL=100; VSLUNT=1 (m); COMPOP=3 (<)]

If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for 
vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. What do you think?

[[User:Rmm|raphael]] 18:29, 13 October 2010 (UTC): OK; both work (in the sense that both allow correct modeling), so if David also prefers option 2, we can agree on that.

[[User:DavidAcland|DavidAcland]] 15:18, 5 November 2010 (UTC): I see good thoughts since I was last here. I see now that multiplicity of COMPOP being 0..2 is wrong.
I think the answer to Raphael's two options posted on 8 Oct is indicated in an example where we have more than one condition; say length and draught as at [[Talk:LOGCON]]. This is getting complicated and I think we need the simplest implementation we can go for. So I favour "exactly one condition" as at Option 1 above and I believe we will need to be able to repeat VLSMSM. I have changed the multiplicity of COMPOP to 1 and everything to Sequential = n/a so that we are coherent with Raphael's advice for Option 1. If Jens warms us to Option 2 we can revisit.

[[User:Jens|jens]] 11:12, 8 November 2010 (UTC) Actually I don't see any need for revising again. We should go ahead with option 1 and see how it works. I only tried to model how it is been written in NPs now: "... applies for vessels of 100 m in length or more or 15 min in beam or more or 10 m in draught or more". I have got no stomachache saying: "applies for
 Vessels of 100 m in length or more
 Vessels of 15 min in beam or more
 Vessels of 10 m in draught or more."
 Thus I accepted the attribute and the proposed option 1 for [[COMPOP]] multiplicity and the ProdSpec.

Rmm at 18:29, 13 October 2010

2010-10-13T18:29:45Z

Jens at 17:26, 13 October 2010

2010-10-13T17:26:33Z

Jens at 10:30, 13 October 2010

2010-10-13T10:30:56Z

Jens at 09:25, 13 October 2010

2010-10-13T09:25:58Z

Rmm at 04:01, 8 October 2010

2010-10-08T04:01:41Z

Rmm at 03:28, 8 October 2010

2010-10-08T03:28:13Z

New page

← Older revision		Revision as of 18:29, 13 October 2010
Line 38:		Line 38:
	If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for <br>		If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for <br>
	vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. <br> What do you think?		vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. <br> What do you think?
		+
		+	[[User:Rmm\|raphael]] 18:29, 13 October 2010 (UTC): OK; both work (in the sense that both allow correct modeling), so if David also prefers option 2, we can agree on that.

← Older revision		Revision as of 17:26, 13 October 2010
Line 13:		Line 13:
	[[User:Jens\|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]		[[User:Jens\|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]

−	[[User:Jens\|jens]] 10:30, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. <br> Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). Do I ~~see~~ it correct?	+	[[User:Jens\|jens]] 17:26, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. <br> Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). <br>
		+	Let's try to explain it with an example:<br> Saying example 5 which is to model <br>
		+	tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP
		+
		+	Using your case 1 I have to model<br>
		+	PILBOP it the feature<br>
		+	APPLIC is the associated information object <br>
		+	LIMTYP 2 (required)<br>
		+	LOGCON 1 (and)<br>
		+	CATVSL=3 (tanker)<br>
		+	# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=50; VSLUNT=1 (m) COMPOP= 1 (>)]<br>
		+	# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=100; VSLUNT=1 (m) COMPOP= 3 (<)]<br>
		+
		+
		+
		+	Using your case 2 I have to model<br>
		+	PILBOP it the feature<br>
		+	APPLIC is the associated information object<br>
		+	LIMTYP 2 (required)<br>
		+	LOGCON 1 (and)<br>
		+	CATVSL=3 (tanker)<br>
		+	#VSLMSM [VSLCAR=10 (L.O.A.); VSLVAL=50; VSLUNT=1 (m); COMPOP=1 (>)], [VSLCAR=10 (L.O.A.); VSLVAL=100; VSLUNT=1 (m); COMPOP=3 (<)]
		+
		+	If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for <br>
		+	vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. <br> What do you think?

← Older revision		Revision as of 10:30, 13 October 2010
Line 12:		Line 12:

	[[User:Jens\|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]		[[User:Jens\|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]
		+
		+	[[User:Jens\|jens]] 10:30, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. <br> Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). Do I see it correct?

← Older revision		Revision as of 09:25, 13 October 2010
Line 10:		Line 10:

	The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).		The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).
		+
		+	[[User:Jens\|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]

← Older revision		Revision as of 04:01, 8 October 2010
Line 4:		Line 4:

	[[User:Rmm\|raphael]] 03:28, 8 October 2010 (UTC): I don't see why the number of COMPOPs should be limited to 2, each COMPOP compares the specified characteristic from own ship data to the VSLVAL with which the COMPOP is associated.		[[User:Rmm\|raphael]] 03:28, 8 October 2010 (UTC): I don't see why the number of COMPOPs should be limited to 2, each COMPOP compares the specified characteristic from own ship data to the VSLVAL with which the COMPOP is associated.
		+
		+	Actually the table of sub-attributes on [[VSLMSM]] as it is today (07 October 2010) should be changed to have either:
		+	* multiplicity = 1 and sequential = "n/a" for all rows; and we allow [[VSLMSM]] itself to be repeated; or
		+	* multiplicity = 1..* and sequential = "true" for all rows, and we don't allow VSLMSM to be repeated.
		+
		+	The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).