-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2-02 Programs/networks: Deprecate entries GALION and GALIONNDACC #189
Comments
Branch created at b9cfcbf#diff-a066c50c20373fc15bcd759e58529c31867ae12caecaa7d36ad7627f5e689622. |
Thanks @joergklausen. Do deprecated entries have a lifecycle (i.e. will they be deleted? If yes, when)? |
Folks, sorry I didn't get to this till now. I was swamped with work last week. I don't recall anyone asking me if its ok to deprecate GALION or GALIONNDACC. Removing the latter (GALIONNDACC) makes sense since NDACC is a GALION network. However, I would prefer to not remove GALION. If that were removed from the programs listing then there would be no way to search for GALION networks. An OSCAR user would have to know what programs were contributing to GALION. I find it odd that the reason to deprecate is that its considered a "coordination mechanism" and not a program? GAW itself is a coordination mechanism, and there are many entries in the programAffiliation code list that are not actual programs: GAW Contributing Networks, GAW other elements, globalAOD, etc .... these exist to provide search fields. SO removing them does not make much sense to me. What is driving this request? |
Good question, I think we need more information by WMO on how this is handled in general. In this particular case, it is a correction and the term should not have entered the code list in the first place. In other cases, where a term has been used in the past, it cannot be simply removed without losing the history, but adding (deprecated) would indicate that it must not be used anymore.
…Sent from my iPhone
On 17 Oct 2020, at 01:34, Tom Kralidis <notifications@github.com> wrote:
Thanks @joergklausen<https://github.com/joergklausen>. Do deprecated entries have a lifecycle (i.e. will they be deleted? If yes, when)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#189 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIFWXY5DSVR7U6VOU2YYF6TSLDKAZANCNFSM4QJSSE3A>.
|
Decision dependant on #199 |
@ejwelton @Netcheva GALION needs to be removed from the WMDR code list, because one cannot affiliate an observation with GALION directly. GALION could remain as a grouping in OSCAR/Surface if WMO agrees, so that one can still search for stations that are coordinated within GALION. This would mean, GALION needs to be listed directly under GAW, because it is not a GAW Contributing network. It remains unclear to me how we should deal with NDACC in this regard. NDACC is one program and they see themselves as such. If the same NDACC is listed under GALION and under GAW Other Elements, then the consequence is that a search for GALION will also return all NDACC stations that have no lidar observations. The only solution to cleanly separate these parts of NDACC is to actually split it up into, say NDACC-main and NDACC-lidar. @ejwelton Could you engage with Jeannette to find a solution? |
You can definitely assign an observation to GALION, I've done this in the XML files I was generating for MPLNET. Even while not done with that process yet, I've tested doing so and it works fine. So I don't understand that comment. As I've said, there are other "programs" listed in the programAffiliation code list that are not individual programs (like global AOD). I don't understand why there is such focus on GALION right now. I've identified many other much more pressing vocabulary / code list issues that have not been addressed yet. Regarding NDACC: I don't see a problem here. Whoever is responsible for updating NDACC in OSCAR would just add GALION affiliation for their sites that have lidar. Just like I could add or remove GALION affiliation for any of my MPLNET sites if one of them did not want to be listed as GALION. |
In agreement with Jörg I would like to propose the following approach to deal with this problem: Proposal GAW
> GAW Other elements
... Reason Branch View differences: 2268f3f#diff-178d0ba48282279e1a03f1d2dc6739a7ff8999a4f14acc531aa8144af5383986 |
I am not sure what these GitHub branches are, I cannot access those links. However, I am still opposed to the idea of deprecating GALION. It makes no sense to me, and given the many other serious problems and issues in OSCAR I don't understand why time is being wasted on this issue. To be clear, WMO, GAW and/or GALION do not coordinate any lidar network. Our networks existed prior to the creation of GALION, and will likely outlast it given attempts like this to remove it. We (the leads of the lidar networks), coordinate GALION! Not the other way around. It is improper to add the word (GALION) to our network names as that implies that we are some sort of WMO funded GAW project. We are independent networks that have agreed to collaborate with GAW, and that collaboration vehicle is GALION. If GALION is deprecated within OSCAR then the entire concept of GALION is erased. What is the point of it? As the GALION co-chair I'm 100% against this action. This whole action seems to have begun due to the GALIONNDACC entry. Why not just clean up NDACC in system and leave GALION as is. |
Hi @ejwelton, my mandate here is to reflect the reality and correct previous mistakes in the official WIGOS code tables. How OSCAR/Surface can deal with this is a related but not the same issue. According to WMO (Oksana), there is no written MoU or LoA that would authorize a code list entry GALION in the program/network codelist - if you want to dispute this, I refer you to WMO. According to your own reasoning, the lidar networks presently listed under GALION are not part of an official GALION network. Therefore, this node cannot be listed, and a direct affiliation with GALION is improper. However, you also insist that you would like to preserve GALION in this tree somehow. The proposal to mention GALION in parentheses is an attempt to preserve GALION as a collaboration vehicle, so that stations that collaborate under this acronym can be searched and found collectively in OSCAR/Surface. The individual networks are directly listed as indicated in the comment above, where NDACC has always collaborated with GAW but never signed an agreement to become a GAW Contributing Network. NDACC is very broad and only a subset of stations perform lidar observations, and that is why the proposal would list the lidar part of NDACC separately. This, BTW, would need to be approved by jeannette.wild@noaa.gov. |
I do not see why this has to be so complicated. Keep GALION as a separate entity from NDACC. There are sites associated with NDACC that have no GALION instruments. There are sites associated with GALION that have no NDACC instruments. Just like SHADOZ and NDACC have some shared sites, and some distinct to each. There is no formal MOU between GALION and NDACC, so GALION should not be considered a subset of NDACC ( or any other network). If there were an MOU, GALION would be a Cooperating Network in our nomenclature. That would mean it is a fully operating independent network. Why can't WMO/OSCAR provide a tool to search GALION sites, and/or NDACC sites? That logic seems simple enough. If they are truly independent that should be easy to execute. |
If an MOU is required to add a word to a code list in your metadata system, then I think there are larger problems to sort out that have nothing to do with me. So it seems to me that the decision to deprecate GALION was already made, yet for some reason this issue was created in GitHub for commentary? The opening comment on this issue indicated that I had agreed to this decision, and my responses thus far have simply been to say that I did not even know about this proposal and continue to disagree with this decision. Thus far I've heard from a representative of AD-Net and they are indifferent to these changes. Jeanette can represent NDACC, and I have no response from EARLINET or LALINET yet. I will just reiterate one last time that the existing implementation of GALION within OSCAR works just fine from a user point of view. It is very easy to either affiliate GALION to a site with a lidar, or choose not to do so. There is no problem from my end. The GALIONNDACC entry should be removed, its unnecessary and confusing. Other than that, since this issue was opened for commentary I will just let my objection stand to deprecating GALION and modifying the MPLNET entry in OSCAR to read MPLNET (GALION). |
Just in case my note was not clear. NDACC and GALION are completely distinct from each other. There should be no GALIONNDACC or NDACC (GALION) entry in OSCAR. This would imply one is a subset of the other, or one is managed by the other. Neither is true. Some sites should show an NDACC affiliation, and some sites should show a GALION affiliation. Sometimes these will intersect, sometimes they will not. As Judd indicates, NDACC is not coordinated by GALION, though the lidar sites may have an affiliation with both. |
The original reason given for deprecating GALION was that it "is a mere coordination mechanism within the GAW program and not a program in itself." The more recently provided reason is "According to WMO (Oksana), there is no written MoU or LoA that would authorize a code list entry GALION in the program/network codelist." As I've mentioned, there are many entries in the Program Affiliation code list that do not meet these criteria either. How is the GAW Aerosol Lidar Observation Network (GALION) any different than the following entries which are also in the code list: GAW, GAW Contributing Networks, GAW Global, GAW Local, GAW Other Elements, GAW Regional, GAW-PFR, GCOS, also GCW, GOS, have similar series of entries. There are others I could find too, but the code list is long. Most of these are not programs/networks on their own. Why would GALION be expected to have an MOU/LOA with WMO? GALION is a GAW creation. Does GAW have an MOU with itself? So my question is: will these other code list entries be deprecated as well? If so, then you must do whatever is required to clean up and maintain your own database per your requirements (requesting input from me is irrelevant). If this proposal is limited to deprecating GALION only, then my objection stands. Regardless, I don't want my network listed as MPLNET (GALION) in any database. |
GALION label should be made available similar to "Centennial" with the approval of the label for individual stations of contributing and other networks as well as GAW Regional/Global/Local stations. |
I do not know what a "label" means in terms of OSCAR metadata. Network affiliation within OSCAR is achieved with the programAffiliation code list. I thought this issue was about deprecating GALION from this list. What is a "label" and how does that relate to program affiliation? Please keep in mind that your system is very complicated and contributing networks must maintain our metadata entires. I have never heard the word label, and thus do not know how to use that in lieu of programAffiliation. Can you explain? If there is a way to maintain GALION as a search option then that is fine with me. |
Thanks to all who participated in the discussion, I summarize as follows, with a nuance: Proposal Reason Consequences for GAWSIS-OSCAR/Surface The proposed changes are implemented at @ejwelton @jdwild @tarasova-wmo Please review and confirm agreement with this branch so that we can hopefully conclude this discussion. |
I concur with the final proposal. Its all ok with me. Thanks |
agree with the proposal |
2 of 3 stakeholders agree, no response from @jdwild yet, but assumed to also concur. Branch is confirmed. |
I also agree. Sorry I was not available yesterday to respond to this. |
I was having difficulty merging the original branch - please edit this new branch with the proposed amendments: https://github.com/wmo-im/wmds/tree/issue189-FT apologies for the extra work.... |
@amilan17, @joergklausen I edited the new branch, view differences: 87ecf78 |
@fstuerzl - 2-02 still has: GALION,\WIGOS\GAW,GALION,GAW Aerosol Lidar Observation Network |
@amilan17, sorry, I have corrected the path now to \WIGOS\GAW\GALION". |
@fstuerzl
Issue-#189...issue189-FT#diff-a066c50c20373fc15bcd759e58529c31867ae12caecaa7d36ad7627f5e689622 |
@amilan17 now, you have me confused, too. Sorry, if I got anything wrong...
Isn't this what @joergklausen's proposal intended? |
@joergklausen Can you please verify this branch? |
Branch https://github.com/wmo-im/wmds/compare/issue189-FT positively validated, all looks good. |
@joergklausen, @amilan I think, I found a mistake in this branch. In #187 CIS-LiNet is under GAW Other elements, and not under GAW Contributing networks. I will correct it in the new branch now. View changes: a497826#diff-a066c50c20373fc15bcd759e58529c31867ae12caecaa7d36ad7627f5e689622 @joergklausen, could you please verify the branch again? |
Proposal
Deprecate existing entries GALION and GALIONNDACC.
Reason
GALION is a mere coordination mechanism within the GAW program and not a program in itself. Hence, the existing entries GALION and GALIONNDACC must be deprecated. The proposal is already agreed with the chief of the GAW program, Oksana Tarasova, as well as GALION co-chair @ejwelton.
Branch
https://github.com/wmo-im/wmds/tree/issue189-FT
don't use: https://github.com/wmo-im/wmds/tree/Issue-%23189
The text was updated successfully, but these errors were encountered: