Talk:RXNCOD

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search

raphael 05:35, 17 August 2009 (UTC):

RXNCOD (Regulation/restriction/regulation code) is intended to provide numeric codes that identify the information as one of the most common types of regulations (or restrictions, etc.) RXNCOD values are precise enough for an application to display specific alerts. RXNCOD values may correspond to specific text ("e.g., pilotage compulsory"). Applications could use RXNCOD to display specific strings, or provide and handle specific alerts.


jens 08:36, 15 September 2009 (UTC)

Long time ago we discussed the idea of providing more detailed information of res/rec/reg but withdrawn our ideas. We saw that too much differences and dependencies are possible. If we start one we have to collect all (pilotage recommended, stand away from bridge before passage is allowed, do not cross etc.). That was our argument. And presumably we will not be able to collect all, or even we produce an endless list. Thus we decided not to further granulate the information. I see that the code can be used for recommending agreed headlines of res/rec/reg. That would look to me better than the proposed structure; at least at the moment.

raphael 07:25, 17 September 2009 (UTC): Example of headline, please? (I'm wondering whether using it that way might duplicate what CATRXN does.)

Also, my thought was that coding even just the most common 10-15 types might still suffice to cover many or most of actual regulations (rec/res), perhaps enough that applications could do useful things with them even if the RXNCOD list is not a 100% complete and perfect capture.

jens 09:07, 17 September 2009 (UTC)

My problem is that I know what will happen. The minority which is not covered by the values will be the discussion point.

In my previous post I thought on using the values as headlines if one needs to encode res/rec/reg. I know the headlines would rather be suggested than agreed headlines. The most of the res/rec/reg are to be used in conjunction with other features e.g. Quarantine and health . That can be modeled PRTARE/REGLTS and the headline can be quarantine. We should not try to split up each possibility of reg/res/rec. As you know, the Law is endless in variations word wide.
The next escalation can be to model each possible Rules of Thumbs; Key West was experience enough to me. At the moment I can not see that using RXNCOD as it is now is a convenient way.

raphael 02:18, 18 September 2009 (UTC): For the "headlines" idea, would the enumeration be the same as for CATRXN as currently defined or would it be some or all of the current RXNCOD values, or some combination of the two?


jens 05:46, 23 September 2009 (UTC)

Sorry for being late with my response. I was too busy the last days.
However, the headline idea can be a mix of CATRXN and RXNCOD values. I am not convinced that all of those are to be used. As mentioned before I am much in favour to assign the res/rec/reg to a specified feature.

For the problem of different kinds of res/rec/reg pertain to one feature I repeated your post at CATRXN because it seems this is in relationship to this discussion. 

   Also, there may be different kinds of reg/res/rec for a specific area. If CATRXN is allowed to take any values
   from its enumeration we can separate different kinds of reg/rec/res even if they are associated with the same 
   feature object.

For that case we can use multiple feature objects sharing the same geometry or using different headlines. Both options are possible.
As I stated before the headlines can only be a recommendation for entries to be placed at TXTDSC.
Recently we discussed regs for anchorages in the Brest area (FR). They can be associated to anchorage places/areas. But the regs are divided in very many different headlines. Some of them are dealing with the anchorage itself others with the law behind that regs or the responsible body or the rules how, when, to whom, why, which vsl dimensions etc., means endless.
In that case we spotted that the idea of having an option to assign one reg/res/rec to several features is brilliant. We hope it will become part of S100.
However, the headlines should not be stringent. We should allow flexibility otherwise we will crash. And we can definitely not offer "others". Perhaps it is thinkable to say we offer some headlines options to be used in TXTDSC but the way to spot headlines in any case is to assign a specified tag to that headline. I know that depends on the result of TXTDSC discussion.
What do you think?


jens 05:49, 23 September 2009 (UTC)

Just thought to take the headlines off the TXTDSC. But than we are exactly there where we started. I only wrote this to avoid start thinking that again. :)

raphael 04:39, 24 September 2009 (UTC): Doed "headlines" mean the topic sub-headings in sailing directions? I was thinking of using CATRXN for topics/sub-topics. Would it be possible to get a few samples from SHOM? (French may do, I should be able to figure out enough to understand the problem even though I do not know French.)

For the anchorages question woudl it work to: (1) place the name of the law or issuing authority (if any) in REGLTS/OBJNAM,(2) use or extend CHALIM to describe who and which vessel dimensions, some kinds of "when" (at night?), and (3) keep "How", "when", "why" as text in REGLTS/TXTDSC?


jens 05:34, 25 September 2009 (UTC)

Yes, for the last entry I would suggest such approach.
For the first item I asked FR to provide such example.

raphael 07:53, 2 October 2009 (UTC): Perhaps adding a text attribute for the section title of the regulation (new attribute RTITLE or RUBRIC or ???) to REGLTS would help? (I hesitate to use OBJNAM for too many things.)

Additionally, the codelists for CATRXN and RXNCOD could be revised as needed.

raphael 18:50, 2 October 2009 (UTC): To clarify and adapt the first point I mentioned on October 2, I was thinking of multiple REGLTS objects for the FR example. We could split the regulations over them as appropriate and use the titles of Articles in the new title attribute.

If it is necessary to collect these REGLTS object into a specified sequence for some reason, an aggregation object may do, or a new complex information object can be defined.

jens 17:48, 5 October 2009 (UTC)

That sounds to me like a reasonable approach. The title attribute is not limited to any predefined lists. The attribute is also not limited to styles attached in the TXTDSC file. That keeps the TXTDSC discussion separated from this discussion. For certain reasons information composition might require an order of information. Thus I would prefer to see complexity.
In a first iteration the construction developed could be a feature with multiple information objects associated, each information object with one headline and some subtitles/subsection and content related to that subtitle/subsection.
In any case we should consider, that searching for attribute values is not possible in that case. OEMs should provide search capacity for the headlines or the content in the text files. On the other hand the construction allows OEMs to provide a menu tree without loading the whole content and let the mariner select the information needed. That sounds very nice to me now.

Feature
..some describing attributes


..Information object CHALIM if applicable


Information object 1
..OBJNAM 1 (that can be a headline to summarise the information underneath)
..RTITLE (1)1..* (subtitle/subsections of OBJNAM 1)
....TXTDSC (information)

Information object 2
..OBJNAM 2 (that can be a headline to summarise the information underneath)
..RTITLE (2)1..* (subtitle/subsections of the OBJNAM 2)
....TXTDSC (information)

and so forth.

Currently I have neither an idea how the aggregation can improve the idea in a way to provide an information order nor I know how a complex attribute is helpful. For the complex idea I don't know how to define the "sequential" entry for multiple instances of RTITLE. But having such sequential available would be much helpful.

Discussions lead to the question whether it is necessry to provide the RTITLE in any case. We think it will not be simple all the time to find a proper headline but we should have our audience in focus. The mariner will be happy having to read only headlines, select what aplies and studying only the relevant information. Conclusion: RTITLE as mandatory attribute defined in ProdSpec. What do you think?


jens 17:43, 6 October 2009 (UTC)

improved the post Oct. 5.


DavidAcland 13:53, 31 December 2009 (UTC). Again - apologies for my late entry to the discussion.

In this list at present we have have apples and oranges. We start with the format:

[activity][control]; i.e. [Pilotage][compulsory] ...
and then we morf into [activity][not quite sure - probably information].

So that makes me think, perhaps we should go complex, with the added benefit that it would act to restrain the endless list.

First element [activity]:
pilotage; entry; passage (if this is different to entry); anchorage; landing; overtaking; speed; tugs; cargo operations; obtaining clearance from customs, immigration and health authority (together or separate); ...

Second element [control]:
prohibited, restricted (conditionally prohibited (weather, time, vessel dimension)); mandatory; uncontrolled; ...

This approach would use the TXTDSC for the pure information which did not contain control and that would mean that we lose the RUBRIC or "heading" element, which I think is good. So could we have an initial heading element along these lines:
first element [heading (Jens's RUBRIC)]
second element [activity]
third element [control]
For example:
[heading] Northern Right Whale Critical Habitat
[activity] Entry
[control] Restricted
The detail, time of year, type of ship, speed restriction, noise restriction, special lookout, actions to avoid collision would all be in the TXTDSC and may also contain the verbatim national regulation. However this is tricky when it involves translation.

raphael 20:14, 4 January 2010 (UTC): This would be more work for the encoder than I had originally envisaged, but if it it is desired and it works for all the situations, the [activity][control] model should be fine. I think if the content is in TXTDSC, the attribute title (subject, heading, RUBRIC) would be useful to have.

jens 10:08, 5 January 2010 (UTC) ok; checked David's structure with both paper and ENC cartographers. Both confirm that the "entry prohibited" is placed as plain text in the area. The ENC contains a TXTDSC construction with that information. That cause no automatic alarm or indication in an ECDIS. At the moment ECDIS provides an information that an area with certain limitations is in a predefined (by ship's settings) distance.
It seems to me David's structure is very similar to others like geography/cause/effect. That looks fine to me.
Can we come to the conclusion that RUBRIC should be renamed to (subject, heading, topic, theme or ...)? That is an English question now.
Can we agree that LIMTYP will fit David's [control] idea above? Presumably amendments and extensions of definitions are necessary, but generally the idea is brilliant and supports David's construction.

DavidAcland 16:59, 21 January 2010 (UTC) I have taken the RUBRIC idea forward with a new attribute SUBJCT
DavidAcland 15:59, 22 January 2010 (UTC)
... and redrafting the idea of RXNCOD as a complex attribute. Placing the present RXNCOD into Deleted items as RXNCODOriginal.


jens 10:24, 22 February 2010 (UTC) At the moment a have got problems with the RXNCOD idea , as tempting good the idea is as difficult their use will be. Perhaps we should try to think a different way.
If we intent to keep this idea alive why not trying to use only SUBJCT and LIMTYP in combination with CHALIM. At the moment I don't see for what ACTION should be used for. The list is neither representative not complete. It looks more like a loose collection.
In any case I see difficulties to separate the use of RXNCOD and CATRXN.

DavidAcland 10:14, 9 February 2011 (UTC) Trying to progress this area. We have agreed that LIMTYP is replaced by CATREL so I will make that substitution, noting that CATREL also sits directly on APPLICABILITY in the MPA application schema. That may not be a problem.

jens 06:58, 11 February 2011 (UTC)
no problems with CATREL and APPLIC as they are now. RXNCOD makes more headache at the moment.
I see CATREL as a good one in relation that it describes how the information object "APPLICABILITY" controls the relationship between other objects depending on ship's characteristics. I can also see that CATREL can be used to express the level of insistence for or against a course of action. The latter explanation is rather in relation to RXNCOD than the first one. Seeing the proposed definition and intention of RXNCOD I am not sure that it is not a kind of duplication of what was made with APPLIC and CATREL. Seeing further the value 5 of ACTION and compare it with the example given for SUBJCT I have difficulties to identify differences.
What do you think to retire RXNCOD for a while and to reanimate it only if we see it is needed urgently to express content better or more structured. Or alternatively, retire one SUBJCT or ACTION. My preference would be SUBJCT. That keeps the data model more keyword search friendly.


DavidAcland 15:55, 11 February 2011 (UTC) OK To summarise: CATREL is now more or less agreed; we also now have MBRSHP. Jens proposes retiring RXNCOD and SUBJCT. The weakness of ACTION is that it is an endless list. CATREL says that something is "Mandatory" or "Verboten". ACTION expresses what that "something" is. This indicates to me that we have to work on ACTION to make it as complete as possible and have a way of dealing with things, which are not covered, without using "Others".

I think we still have at least three ideas to deal with on this subject: CATTXT, TXTDSC and LAWLAW. I assume that the entire regulation, extracts from it, or an abstract or summary will be in a TXTDSC. Do we still need to find a place for CATTXT to say which of these it is? I have not been able to find it, but I remember seeing LAWLAW somewhere recently. Is this somehow related?

I plan to continue working on ACTION on Monday unless I hear that is the wrong direction.

jens 19:07, 11 February 2011 (UTC) many thanks for keeping my mind running over the weekend. ;)

raphael 21:21, 11 February 2011 (UTC): I'm willing to pursue ACTION and see where it takes us.

jens 12:34, 13 February 2011 (UTC) I suggest to try the model on an example. Following extract of SDs 

Compulsory reporting	
  vessels of 50 m length and above including pushed or towed composite units
    only if no report was given to German Bight Traffic Control see C 2.1.1
  vessels carrying dangerous or environmental polluting goods see also chapter A 3.1
    including unloaded tankers if not cleaned, gas-free or completely inerted after carrying petroleum/petroleum products with a flashpoint below
    35° C

can be modelled 

Feature: MRNSRV/ CATMSV=1 (VTS)/ 
  Association: SHPREP/ CATREP=1 (Sailing Plan)/ IMOREP=1 (yes)
     Association:  APPLIC / VSLMSM [VSLCAR=1 (length); VSLVAL=50; VSLUNT=1 (m); COMPOP=2 (>=)] 
          Association: REGLTS / CATAUT=15 (maritime) / MBRSHP=1 (included)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (if no report was given to German Bight Traffic Control)]  
     Association:  APPLIC / VSLMSM [VSLCAR=1 (length); VSLVAL=50; VSLUNT=1 (m); COMPOP=2 (>=)]/ LOGCON=1/ CATVSL=13 (pushed units+towed units)
          Association: REGLTS / CATAUT=15 (maritime) / MBRSHP=1 (included)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (if no report was give to German Bight Traffic Control)]
     Association:  APPLIC / CATCGO=7 (dangerous)/ CATDHC=20 (miscellaneous)
          Association: REGLTS / CATAUT=15 (maritime)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (what is stated at A 3.1)]
     Association:  APPLIC / CATCGO=7 (dangerous)/ CATDHC=1-20 (all)/ CATVSL=3 (tanker) Actually I have difficulties to specify the given cargo information completely 
          Association: REGLTS / CATAUT=15 (maritime)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (what is stated at A 3.1)]

Although the example looks a bit strange I guess, we can employ RXNCOD as complex attribute containing ACTION (to be extended and hopefully completed), CATTXT (to describe the completeness of the information provided) and TXTDSC (to carry the relevant text file).
I don't see SUBJCT, LAWLAW to be used.
It is to consider if CATRXN should b placed elsewhere here. This attribute was developed and is still not used anywhere.


A further thought is about MBRSHP. It is to discuss whether it is possible to use it to include always each second vessel description to each first APPLIC. I am not sure but it looks very tempting.


DavidAcland 17:42, 14 February 2011 (UTC) You are right; this is hard.
I follow some of the logic but am struggling. I do not see how to encode "unloaded tankers if not cleaned, gas-free or completely inerted after carrying petroleum/petroleum products with a flashpoint below 35°C". I feel that has to be text. My basic parsing is to say: Marine service area:
reporting: compulsory (except if Report given to German Bight Control)
for vessels over 50m length
for composite tugs and tows
for vessels carring DHC
for "unloaded tankers if not cleaned, gas-free or completely inerted after carrying petroleum/petroleum products with a flashpoint below 35°C".
I am struggling additionally because I do not know whether the cross references "see ..." and "see also ..." apply to all the cases before them or just the composite units and the unladen tankers; and because I do not know the particular bit of water this applies to. Somehow I do not expect to see pusher units in the open sea and so it seems likely that it is in some fairy sheltered waterway.
The "Compulsory except if" is also frying my brain. This sounds to me as if we need more complexity on the CATREL which I am not keen on.

jens 18:20, 14 February 2011 (UTC) Sorry David, that confuses me.


"reporting: compulsory" Actually compulsory does not exist neither as attribute nor as attribute value. ??to be added elsewhere but where and which other values are thinkable??
the next three lines are fine
for "unloaded....35°C" somehow stated in TXTDSC. What we need is the path how to get to that TXTDSC in a way that one understands that the content is beyond what was modelled.



I hope that doesn't confuse you now. lol


DavidAcland 18:28, 14 February 2011 (UTC) OK not "compulsory" - "Required". Our edits crashed so I copied my last and reposted above. I meant:

Reporting is (ACTION = 13) - My earlier "Activity"

Required is (CATREL = 5) - My earlier "Control"

and these would both be sub-attributes of RXNCOD.

jens 05:47, 15 February 2011 (UTC) Again, it came uip over night. The problem with "required". It is nice modeled as it is now. No problem with that. Do we need that for the example above? I don't think so. If SHPREP and APPLIC working together as they should than it seems obvious that the ships have to make that report.
So finally, ok as it is modeled now. Not necessarily to be used at the example above.


The cross reference to C 2.1.1 is been used to point where the reports to German Bight Traffic Control are described in length.


The cross reference to 3.1 applies for all in the appropriate hierarchy vsl carrying DG and unloaded tankers with ....

raphael 07:19, 15 February 2011 (UTC): I don't think we should try to use enumerations or numeric attributes to model unique conditions like "except if report given to GB Control" or "unloaded tankers if not cleaned, gas-free or completely inerted after carrying petroleum/petroleum products with a flashpoint below 35°C". We can just keep such conditions as text.

Length, whether it is carrying DHC, whether it is a tanker, towed or pushed, etc., are all more common and these can be captured in an enumeration (for types of vessel, cargo, etc.) or value (for LOA, beam, draught).

How about this as a general principle: Unique conditions are encoded as text in some free text or general-purpose attribute, e.g., INFORM or TXTDSC (or perhaps we want to define a new text attribute for text conditions, "ConditionApplyingToVessel"). Common conditions are encoded as an enumeration or numeric attribute.

DavidAcland 12:19, 15 February 2011 (UTC) Yes I agree with "Reporting" and using SHPREP the message is fairly clear and perhaps we should take "Reporting" out of ACTION to avoid duplication. If it was a different activity like "Port entry" or "Passage", where we do not have a ready made and tailored feature, we would need something else.

I think we all agree with your logic, Raphhael:
Common and simple characteristics or conditions should be enumerations;
All others have to be gathered as text. As Jens has already foreseen this means that they cannot play into the subsequent machine readable and rule based ECDIS behaviour. And so we have already started talking about the exceptions.
Would it be reasonable to leave this discussion like this but to put down a marker to return at some future date to individual cases, where we have had to resort to text, and to see if we can group some of those together and standardise them into extensions of existing attributes?

raphael 17:07, 15 February 2011 (UTC): Yes, putting down a marker for exceptional or unique conditions sounds like a good idea.

On SHPREP and "reporting" as an action - keeping "reporting" as an action is better because it makes the list of allowed values more complete. If the software has to determine some meanings by looking at an enumeration attribute of object X, and other meanings by looking at which objects X is linked to (or worse, which objects link to X) that will complicate the software a lot.

We should use "required" for similar reasons - modeling the other meanings ("prohibited", "recommended", ...) by the value of an attribute, but "required" by the absence of the attribute makes the model more complicated.

jens 10:36, 16 February 2011 (UTC) Hoping to understand you correctly all is fine as it is now. We keep required and reporting where they are now and play around with further examples to see how we can resolve the puzzle of undefinable exemptions.

raphael 17:42, 16 February 2011 (UTC): Yes, that's what I thought. We collect examples of such undefinable conditions (perhaps in a new spreadsheet?). Later, we see if there are enough similarities in the collection to justify extending the model by adding new allowed values, attributes, or objects.

DavidAcland 10:13, 22 February 2011 (UTC) OK I think we are moving towards agreement on RXNCOD.

SUBJCT remains to be agreed. I see that it is mandatory at the moment. I believe it should be optional. There may be times where the regulation is "Anchoring Prohibited" when it would be useful to known that this is as the result of for instance: "Protection of seabed habitat" or "Traffic regulations". On other occasions such as perhaps "Fishing prohibited" when a SUBJCT of "Fishing Regulations" would be redundant. So I propose to change Multiplicity of SUBJCT from 1 to 1..0

raphael 03:52, 23 February 2011 (UTC): I have doubts about making SUBJCT optional. I agree that is sometimes redundant, but on the other hand it would complicate the software to have two ways of determining the subject, instead of just one way. Also, SUBJCT might make a convenient section, paragraph, or column title for portrayal.

DavidAcland 10:41, 23 February 2011 (UTC) OK. No change required then.

DavidAcland 10:20, 26 January 2012 (UTC): I see that the Blast Report to SNPWG14 refers to the BLAST product spec for DMRG (SNPWG13-7A)and that RXNCOD is used in this document. I will therefore now try to bring this to agreement.

jens 12:25, 27 January 2012 (UTC) Having the BLAST modelling experience in mind I don't see that I have to use this attribute. I read all the comments we posted years ago and I'm not longer convinced that the attribute provides improvements to the current model. We should come up with an example showing the benefits. Otherwise we can continue with the attributes we have used already and move this to the "deleted" section.
Or is the AbstractRXN used at the MPA UML the result of the discussion? I was told that it doesn't carry additional information. We have to specify the values if it does.

raphael 18:22, 27 January 2012 (UTC): The proof of the BLAST pudding will be in the BLAST digital mariner's routeing guide prototype; can we revisit this discussion after that is implemented?

jens 08:25, 30 January 2012 (UTC) O.K. Raphael, Let's do this way.

DavidAcland 09:16, 3 April 2012 (UTC)

Further to the Action I received from SNPWG14 to try to combine RXNCOD and CATRXN, I have reviewed CATAUT and CATRXN. I discovered a few identical enumerations and several very similar ideas. With some redrafting I have combined the two to produce a list of 17. If this works, we can decide on the best alpha name later but for the moment I am using CATAUT.

I have also reviewed ACTION and suggest we revert to an earlier name "activity" I have added two enumerations, "Weighing anchor" and "slipping" to make the list more balanced. For the moment I am keeping "dredging" and "drilling" on hold because I do not think we have a strong enough case to add them. However we could add these if there is a good reason to do so. They come from the idea of commercial exploitation of the seabed - as an extention of fishing being commercial exploitation of the water column. I am emailing the homework on this to Jens and Raphael in a separate spreadsheet.

And so to the main task. My only proposal is to add the new combined CATAUT/CATRXN attribute to RXNCOD as now shown at the page. This would mean:

The type of regulation is discoverable by an ECDIS using CATAUT/CATRXN. We use SUBJCT if no CATAUT/CATRXN enumeration covers the subject properly. Its impact would be described by a combination of activity and CATREL.

Does this make sense to anyone else?

jens 08:48, 10 April 2012 (UTC) I see the logic behind and I like the idea. What I don't see is how SUBJCT can be used if CATAUT is not sufficent; as stated at the comments. Rather I think that an ECIDS system can use CATAUT to link the information objects and RXNCOD. SUBJCT can be used if ACTION enumerations fail.

By Raphael:

About CatAuthReg: If a port authority limits speed within port limits, isn’t that a regulation affecting navigation (value=1), issued by a port authority (value=2)? The point being that CATAUT states who issued the (say) regulation, and CATRXN states what the regulation controls. I expect masters and navigation officers would be interested equally or more in which part of their work (i.e., monitoring of navigation, communications, filing paperwork, etc.), is affected, than who issued the rule, recommendation or note.


About Activity:

(1) Imperfect as they are, either Action or Activity seems good enough a name. Alternatively we could rename this as ActionOrActivity.

(2) The enumeration looks all right to me, just a remark and a question:

a. The list need not be complete, just define the actions or activities which are most often the subject of a regulation, restriction, recommendation, or note. If it captures say 90% of the activities that may be good enough.

b. Should there be a catchall category “other”, defined as an action or activity not defined by the other categories? This would be for miscellaneous infrequently-regulated actions/activities.


jens 10:09, 10 April 2012 (UTC) I don't support the catchall category "other". I see it from the user's point of view. He will get a display saying "Action/Activity: other". Other from what?, would be the logical question. S57 is using "unknown" or "not specified" if the correct value of an attribute can not be provided.

DavidAcland 10:27, 10 April 2012 (UTC)

Thank you for these comments.

Raphael, I think you make a good case to keep the type of authority separate from the type of regulation. So I will keep the changes to extending the lists accepting that we do not need to achieve 100%.

So far we have tried to avoid the let out "Other", and I think we only have the idea in "CATREP" because IMO does. There the final enumeration is "Other report".

Jens, in your entry above you say:

"SUBJCT can be used if ACTION enumerations fail."

I wonder if this is right. I thought SUBJCT grew out of RUBRIC, and I thought that that was to be the subject or headline for a set of Regulations. I would therefore see it as the fall back in case CATRXN could not properly describe a kind of regulation.

Or are we looking for let outs for both CATRXN and ACTION?

raphael 05:47, 11 April 2012 (UTC): Unknown or unspecified (encoded as a null or absent attribute?) instead of "other" is all right.

Using SUBJCT as a substitute if the enumerations fail: If I understand the discussion correctly, I think the thinking is that SUBJCT could indeed be a let out (fallback/substitute) for both CATRXN and ACTION? I would agree with this.

DavidAcland 16:15, 11 April 2012 (UTC) OK. This looks like progress. However I would not support using SUBJCT as it is currently drafted as the let out for two or more ideas.

If we did want to use the same attribute to support multiple precise lists like CATAUT, CATRXN, CATTRA etc, could we not just use INFORM? If that is not good science, an alternative would be to design a general text attribute for that slightly different purpose.

jens 05:54, 12 April 2012 (UTC) I tried to compare the discussion with what we did with BLAST mapping. I frequently used an attribute "header or something like this" HEADNG to indicate what the main purpose of the reg/res/rec/ninf is. During the modeling, I left CATRXN intentionally open because the use of it was not 100% clear for me. Nowadays I see the advantage of having RXNCOD and thus CATRXN to make the data more accessible.

raphael 13:38, 12 April 2012 (UTC): Wouldn't INFORM be needed to encode something else, like the substance of the regulation? I am open to revising SUBJCT or using HEADNG (maybe call it "Header" or "Rubric", because in the hydrographic context "ship's heading" may be a stronger connotation than "title" or "header").

DavidAcland 15:32, 12 April 2012 (UTC) OK. Good points. So not INFORM or HEADING. However the important thing for me is that we are confirming the need for one attribute to be a letout for ACTION, currently SUBJCT, and another to "indicate the main purpose of the reg/res/rec/ninf". I will think about a name for this on the way home.

jens 11:42, 13 April 2012 (UTC) I thought the main purpose of the quartet is covered by CATRXN now. I see also that the BLAST way, trying to find a header for a particular entry of the quartets content, is not the best way for software to access the information properly. The header, if requested, can be modeled or styled in the file provided by the quartet.
What we need is the letout if the enumerations at ACTION are not sufficient.

DavidAcland 12:55, 4 May 2012 (UTC) At last I have found some time to continue this work. I have extended and reordered ACTION. I have extended CATRXN and moved it from the "Proposed" area into the "Attribute" area. I have added a new attribute which is "Action or activty exception" ACTXEP. This is the "letout" for ACTION. I have also re-styled RXNCOD so that SUBJECT is the "letout" for CATRXN. I agree that if we want to create a "Title" or "Heading" attribute to hold the name of the regulation, it fits properly on the quartet item.

DavidAcland 08:57, 8 May 2012 (UTC) Definition of ACTXEP shortened to become identical to ACTION. Now both are shown as distinctions to each other.

raphael (talk) 21:08, 9 January 2017 (CET): Summary of recent e-mail discussion about using RXNCOD in information types Regulations, Restrictions, Recommendations, and Nautical Information

  1. Additional information on the principal subject matter of a “quartet” object would likely be useful (apart from searching the header for key words). Vessels would like the option to filter MPAs based on the 'activity' they are doing. The most obvious would be transiting vessels vs fishing. The majority of the US MPAs have no impact on transit but significant implications for fishing.
  2. ACTION attribute seems most likely for that filtering - especially if the enumerations where expanded a bit to include specific gear-types of fishing (trawl, long-line, ....). (Trawl restrictions may expand into a sub-coding for bottom-trawl in the future.)
  3. CATRXN seems more useful to the management side of things - NOAA has been asking AnthInst to include more of these high-level 'motivation' tags to assist in their own data analysis.
  4. Restrictions are often on specific activities -- fishing, mineral extraction, diving. For most areas, most activities are not outright prohibited but are subject to varying degrees of restriction above the 'norm' for general federal or state waters. The listed values of attributes restriction and categoryOfRestrictedArea (both from S-101) do not allow encoders to describe such nuances.
  5. The use of CATREL as a sub-attribute of complex attribute RXNCOD needs to be reconsidered. Considerations and alternatives are outlined below.
    1. CATREL is used in association class PERMIS, so any side-effects on that part of application schemas should be considered before changing CATREL;
    2. The existing listed values of CATREL might be expanded with a new 'subject to restrictions' listed value;
    3. RXNCOD.CATREL might be replaced with a new boolean attribute: RXNCOD.specificRestrictions (T = specific restrictions exist);
    4. Neither CATREL nor specificRestrictions may be needed. Merely populating the other sub-attributes of RXNCOD or the TXTCON attributes of REGLTS/RESDES indicates that there are specific restrictions.
  6. Given that a header often describes the subject of a paragraph or section, could sub-attribute SUBJCT be replaced by attribute headline which is already defined in the NPUB model? Given the wide variety of subjects, SUBJCT is likely to remain a string type.
  7. The quartet info types are widely used in NPUB application schemas, so the implications for other product specifications should also be considered.

jens (talk) 08:55, 13 January 2017 (CET) It is obvious that RXNCOD should only be used in conjuntion with the quartet info types. Each of those provides an attribute headline as a sub-attribute of textContent/information. So, I agree that the purpose of the initial SUBJCT attribute could be performed by headline and that SUBJCT seems to be superfluous. CATRXN can be expanded to fulfil further requests or can become a open code list. ACTION can also become an open code list. We discussed the option to make it a "dictionary type" code list.

The "main text" of the quartet inf types can provide further information.

So RXNCOD would have only three sub-attributes CATRXN, ACTION and HEADLN. The latter is a copy of the textContent/information/HEADLN.

I'm not in favour to introduce a boolean saying that specific restrictions exist. Publishing at least one of the quartet inf types is saying exactly that. We can assume that no quartet inf types will be publised which content has no effects on navigation.

raphael (talk) 05:34, 18 January 2017 (CET): I think we can proceed on this line (i.e., 3 sub-attributes CATRXN, ACTION, and HEADLN) and try it out.

Retrieved from "http://wp12183585.server-he.de/npubwiki/wiki/index.php?title=Talk:RXNCOD&oldid=8083"