deprecate tot_nitro slot

[mslarae13]

Fixes #680

tot_nitro =
Total nitrogen concentration of water samples, calculated by: total nitrogen = total dissolved nitrogen + particulate nitrogen. Can also be measured without filtering, reported as nitrogen
domain_of:

• HydrocarbonResourcesCores
• HydrocarbonResourcesFluidsSwabs
• WastewaterSludge
• Water

tot_nitro_content =
Total nitrogen content of the sample
domain_of:

• Agriculture
• FoodFarmEnvironment
• MicrobialMatBiofilm
• Sediment
• Soil

tot_nitro & tot_nitro_content are the same, with the exception that tot_nitro is water specific in its description

In this PR,

• marked tot_nitro for deprecation
• changed anywhere tot_nitro it used to now use tot_nitro_content
  • HydrocarbonResourcesFluidsSwabs
  • Water
  • WastewaterSludge
  • HydrocarbonResourcesCores

[cmungall]

What is the MIxS policy on deprecation?

I would not delete this as you have done in the PR. Instead

• mark as deprecated
• and a replacement annotation to tot_nitro_content

[cmungall]

deprecate instead of delete

[mslarae13]

Discuss with CIG
IF there is need for HCR extensions to specify the tot_c content of the WATER vs the sample, we should update the description to emphasize that the water is NOT the same. And the tot_nitro_content should be used for the water extensions as in this case it is the sample.

In short
Is this slot describing a property of the SAMPLE or a some aspect of the ENVIRONMENT in which the sample was collected
See : #664 (comment)

[lschriml]

When this extension was created,  They wanted to specify that it was the water, as they pump water into the line and take the sample of the water, to examine microbes before extracting the oil.   I would not deprecate this term. It is specific to their use case.LynnSent from my iPhoneOn Jul 17, 2024, at 6:31 PM, Montana ***@***.***> wrote: Discuss with CIG IF there is need for HCR extensions to specify the tot_c content of the WATER vs the sample, we should update the description to emphasize that the water is NOT the same. And the tot_nitro_content should be used for the water extensions as in this case it is the sample. In short Is this slot describing a property of the SAMPLE or a some aspect of the ENVIRONMENT in which the sample was collected See : #664 (comment) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mslarae13]

Thanks @lschriml

I realized that from a comment from @cmungall
With that, I agree we could probably close this PR and issue, but we should visit the included discussion to make sure we're providing clear text on when these data as metadata values are about the "sample or a some aspect of the environemnt in which the sample was collected"

[lschriml]

Sounds good. For the hydrocarbon work, they are drilling for oil. After they drill they pump in water, and sample it for microbes.Interestingly, this standard is used across the drill industry.Cheers,LynnSent from my iPhoneOn Jul 19, 2024, at 6:29 PM, Montana ***@***.***> wrote: Thanks @lschriml I realized that from a comment from @cmungall With that, I agree we could probably close this PR and issue, but we should visit the included discussion to make sure we're providing clear text on when these data as metadata values are about the "sample or a some aspect of the environemnt in which the sample was collected" —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[turbomam]

This is a great discussion about user requirements and GSC/MIxS policies, esp. with respect to the LinkML deprecation procedure that has been approved by the TWG.

For me the key issue here is the effort that goes into creating MIxS terms and Checklists/Extensions in support of specific users from specific domains, versus the ongoing effort that goes into managing MIxS as a whole. @mslarae13 has opened a lot of thoughtful issues and PRs about what appear to be redundant terms. Whether they are merged with changes or just closed, the general theme shouldn't be neglected.

Folklore-like reflection on the history of a term can be a great addition to a GitHub ticket like this, but it shouldn't be necessary. At a minimum the descriptions of the two terms (or comments?) should be updated with clear differentiating language. Moving forward, all of this knowledge should be captured in a rolling format that is easy to integrate with the LinkML representation of MIxS.

[lschriml]

On the next CIG/TWG calls, let's start to put the process into place, to ensure we are identifying the suggested changes, into the GSC workflow. To ensure we do not lose the domain experts knowledge that was used to create the standards, while taking advantage of new information to improve MIxS. *To be clear: *we will not be changing terms/definition content, without the process of including the domain expert teams. All suggestions for alternative definitions (descriptions) should go through this process, to ensure the integrity of the information. None of us are experts in all areas, and we have found that working directly with the domain experts is the best path forward. Cheers, Lynn

…

On Mon, Jul 22, 2024 at 11:02 AM Mark Andrew Miller < ***@***.***> wrote: This is a great discussion about user requirements and GSC/MIxS policies, esp. with respect to the LinkML deprecation procedure that has been approved by the TWG. For me the key issue here is the effort that goes into creating MIxS terms and Checklists/Extensions in support of specific users from specific domains, *versus* the ongoing effort that goes into managing MIxS as a whole. @mslarae13 <https://github.com/mslarae13> has opened a lot of thoughtful issues and PRs on this topic, and whether they are merged with changes or just closed, the general theme shouldn't be neglected. Folklore-like reflection on the history of a term can be a great addition to a GitHub ticket like this, but it shouldn't be necessary. At a minimum the descriptions of the two terms (or comments?) should be updated with clear differentiating language. Moving forward, all of this knowledge should be captured in a rolling format that is easy to integrate with the LinkML representation of MIxS. — Reply to this email directly, view it on GitHub <#751 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBB4DJ5DRPK3GEHK7LIG6TZNUNHFAVCNFSM6AAAAABBY45V6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBTGE3TSNRWGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Lynn M. Schriml, Ph.D. Associate Professor Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 ***@***.***