Use of Attributes on Named Associations

[JeffWootton]

Any thoughts on this issue for applicability in S-101 will be appreciated.

Email correspondence between Jonathan Pritchard, Tom Richardson and Jeff Wootton 20-21 November 2024:

From Jonathan:
Hi Tom/Jeff,

Hopefully a quick question. in S-101, we don't use attributes on relationships do we? the 8211 allows for attributes to be included in relationships (feature->feature or feature to information type) but I don't think they're used anywhere or captured in the feature catalogue. Noting that they're still in the 8211 profile in the PS if we don't use them we should probably note that somewhere...

Reply from Tom:
Hi Jonathan

No I don’t believe we do,

I understand NIPWG pushed for this and it is used for their applicability modelling

I would agree that this should be noted but I think it can wait until post 2.0.0 now.

Do you have an example of a spec and FC where they are used?

Reply from Jeff:
Hi Jonathan.

We do not currently use attributes on the relationships, although at some time in the future I think we should look into taking advantage of this possibility. I am thinking here of some of the named associations that we have for the routeing measures such as TrafficSeparationSchemeAggregation – the current TrafficSeparationScheme feature (which has the option of no geometry or surface geometry for name display purposes only) could have its attributes transferred to the TrafficSeparationSchemeAggregation and there would be no reason to retain the TrafficSeparationScheme feature. However, this requires a change to S-100 to allow for the aggregation to use the geometry of its component parts to define its extent and to allow display of the name.

Am happy to note this somewhere in S-101 – perhaps something to raise at PT14?

Reply from Jonathan:
Thanks Tom. NIPWG uses relationship attributes between Applicability and regulation or restriction information types. It’s used to show whether particular vessel types are included or not included in associated restrictions - the association holds the attributes “included” or “not included”. Currently all four NIPWG phase 2 products use them in the same context but none are using 8211 of course…

The reason I ask is I’m trying to work out all the possibilities for update combinations to inform NIWC better about what the art of the possible is with the 8211 implementation.

So… absolutely fine to note it post 2.0.0 - and I’ll scratch the 8211 cases from my list (the association attributes of course have their own add/del/mod instructions in 8211). I’ll share some of the detail of the 8211 cases when I’m done with it.

[rmalyankar]

There are two distinct matters here.
One matter is attributes on associations and I agree that S-101 2.0.0 doesn't use those.
The second matter is Applicability and related concepts, and there is already at least one mistake about them in the top post. Given that Phase 1 is top priority for now, I would recommend not taking up the question of Applicability at this time, given the time needed to explore the nuances.

[TDYCARHugh]

Agree that attributes on associations are not used in S-101.
This and some other modeling choices seem to make sense from an academic perspective when building a UML model or dealing with abstract concepts. The end result of such modeling decisions may not be very attractive when it comes to system implementation, data production and usability. By now we should be considering the practical impact of the existing models and the impact/results of making changes. Real use cases and proof of concepts need to be considered when deciding the way forward.

[kusala9]

this is an example from S-131 of how these attributes are used.

[kusala9]

association types hold attributes determining whether a restriction/regulation etc is applicable to a particular feature type/vessel type.