Modify Variables table to enable greater interoperability #160
Comments
|
I’m really looking forward to being part of this conversation. The risk is that without careful work on a broad but consistent conceptual definition here, that ODM will suffer from the common “Hotel California Syndrome” of environmental data systems where everything can be checked in, but getting it out again depends on a nuanced understanding of how it was put in which soon everyone forgets.
…Sent from my iPhone
On 29 Sep 2018, at 4:49 am, Anthony Aufdenkampe <notifications@github.com<mailto:notifications@github.com>> wrote:
This issue follows up up on my suggestion in ODM2/ODM2DataSharingPortal#71 (comment)<ODM2/ODM2DataSharingPortal#71 (comment)> that we pick up the "800-lb gorilla" issue to reimagine variables as we described our EnviroVariableNames-ODM2TeamIdeas<https://docs.google.com/document/d/1BTOIAphE2bBGC1yOg-qe-2x7HKdeEAMYWHKvJgQUil8/edit#>.
This directly addresses the semantic overloading challenge that we've all been aware of from the beginning and discussed at the April 2014 CUAHSI Ontology Project Capstone workshop<https://docs.google.com/a/stroudcenter.org/document/d/13M6oafP63RYu5Bc_dN7PzdntXaDqJoK1OV_I5G_ihzM/edit#bookmark=id.clv1czuijq6z> and further developed during the May 2016 Environmental Chemistry Names/Ontology Workshop<https://drive.google.com/open?id=0B3v0QxIOuR_naU1pVm5VTjNxTWM>. Most recently @PleiadesAustralia<https://github.com/PleiadesAustralia> raised in this "Semantic overloading of CVVariableName" issue: ODM2/ODM2ControlledVocabularies#35<ODM2/ODM2ControlledVocabularies#35>.
I've been working with @roelofversteeg<https://github.com/roelofversteeg> and we have an idea on how to move forward that allows us to hang on to older Variable/Parameter terms while also breaking down each term into its semantic/conceptual components in a way that enables both more granular queries and cross-walk mapping.
We'll share soon.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#160>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2gx2tzbgAmMQQ18K72o6P9j98CLr7ks5ufotXgaJpZM4W_v4R>.
|
|
In our latest commits to the ODM2.1_dev branch, @roelofversteeg and I have found, we believe, the right balance between:
Our solution also provides the benefit of creating an interoperability system that maps any existing "Variable" or "Parameter" terms to these core concept components, AND therefore provides a means to utilize ODM2 as a "lingua franca" to integrate datasets from different sources for granular, data-value level queries, as we described in our EnviroVariableNames-ODM2TeamIdeas Google Doc. @peckhams describes for his CSDMS Standard Names (CSN) that a "Variable" or "Parameter" term can be broken down into these core concepts (where optional components are in brackets):
Based on our evaluation and discussion in our EnviroVariableNames-ODM2TeamIdeas Google Doc, we broke down the first two concepts a bit further:
Therefore, we believe most Variable terms (from any of the numerous existing, external vocabularies) can be mostly described by these four component concepts which already exist in ODM2:
Where the Taxonomic Classifier term should identify the core object of the variable, such as a "species", typically from a biological, chemical, geological or other kind of taxonomy and preferably taken from an External Identification System, such as:
Where the Medium is considered another object that is containing the object you’re measuring. For a QuantityType that is a ratio, Medium is usually the stuff that is assumed in the denominator of a unit. Where the QuantityKind is presently taken what is presently called the ODM UnitsTypeCV, which in turn is a an modification of QUDT v1.1 QuantityKind terms that were expanded to better include environmental and chemical variables. NOTE that QUDT v2 is in process, and appears to be doing a more complete job with environmental and chemical variables. This approach does not yet include CSN [operations] or [modifiers], but could be expanded to include those if necessary. |
|
Here is an image of the proposed modifications to the Variables and TaxonomicClassifiers tables:
My thinking is that for ODM2.1, we would pre-populate this new Variables table from our existing ODM2 VariableNameCV, after mapping each term to the four core concepts. Likewise, I'm thinking that we would also pre-populate the TaxonomicClassifiers table with all chemical species currently in the ODM2 VariableName and ODM2 Speciation vocabularies. Note that we propose here to eliminate the use of these two vocabularies, some of which is described in #161. |
|
Anthony -
From a biological sampling perspective I cannot see how this would work.
Taxonomic classification is currently the biological taxa of the organism being measured to which a host of criteria apply - namely Abundance metrics, fork length, weight, etc...
Under your model there would be a requirement to register multiple variable for each biological taxa and the overhead from this would be awkward and unsustainable given that the biological taxa can number in the tens of thousands.
Regards,
Sam
…________________________________
From: Anthony Aufdenkampe <notifications@github.com>
Sent: Tuesday, October 30, 2018 5:19 AM
To: ODM2/ODM2
Cc: Samuel Nelson; Mention
Subject: Re: [ODM2/ODM2] Modify Variables table to enable greater interoperability (#160)
Here is an image of the proposed modifications to the Variables and TaxonomicClassifiers tables:
[odm2core_odm2 1_dev_2018-10-29]<https://user-images.githubusercontent.com/5166036/47680602-46d87100-db95-11e8-895f-01c3a3e942b3.png>
[https://user-images.githubusercontent.com/5166036/47680602-46d87100-db95-11e8-895f-01c3a3e942b3.png]
My thinking is that for ODM2.1, we would pre-populate this new Variables table from our existing ODM2 VariableNameCV<http://vocabulary.odm2.org/variablename/>, after mapping each term to the four core concepts.
Likewise, I'm thinking that we would also pre-populate the TaxonomicClassifiers table with all chemical species currently in the ODM2 VariableName<http://vocabulary.odm2.org/variablename/> and ODM2 Speciation<http://vocabulary.odm2.org/speciation/> vocabularies. Note that we propose here to eliminate the use of these two vocabularies, some of which is described in #161<#161>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#160 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g8iwSkNlHNDwQg0JfPSLlYKPnH6oks5up3DMgaJpZM4W_v4R>.
|
|
Maybe I'm not following this closely enough, but largely, I think this just reorganizes/moves stuff that already exists in ODM2. It may not all be in the Variables table now, but there's good reasons for why things are where they are. Why is the suggestion to move the content of the Variable Name CV table into the main Variables table? I see the following comment in this commit (8ad71c4):
First, the "CV_VariableNamenew" was never part of the ODM2 schema (not sure where it came from), and second, wasn't the existing VariableName CV already a "system for mapping to external variable/parameter term lists?" It never relied solely on an internal CV and always had the capability to link to terms from other vocabularies. Why break the convention used by all other CVs in ODM2 when it doesn't add new functionality? Users could already link to URIs for externally defined terms via the existing Variable Name CV. How would they do so now - you have a VariableSourceURI, which implies that there is a source out there that supplies all of the information in your proposed new Variables table, and I don't think there is one. So, I'm not sure what interoperability this would bring. Also - I don't understand why you are suggesting moving Medium into Variables when I think the same arguments you made for keeping other stuff out of Variables (e.g., units) could be made for keeping Medium out of Variables. Wouldn't Medium be a property of the Result (as we had it already) an not a property of a Variable? Temperature is temperature whether it is measured in air or water. Moving the Medium to Variables means that we will be duplicating Variables (now I have to have a variable for temperature in water and another one for temperature in air). Changing the name of VariableTypeCV to VariableDomainCV seems like an unneeded change. It doesn't really add anything new. The absence of a VariableCode will not support many use cases where short codes for Variables are commonly used. QuantityKindCV moves some Units information back into Variables? I know you are proposing that this is equivalent to the UnitsTypeCV, but isn't that a property of Units? It already exists in the Units table that is linked to a Result. I guess I don't really understand how moving it helps. As @PleiadesAustralia notes - there are many variables (particularly biological ones) where the VariableName (e.g., "Count") is qualified by a TaxonomicClassifier (e.g., some species name). I think this:
Goes beyond what a "Variable" is, is missing what we are now calling VariableName, and introduces a higher level concept that is not represented by a specific entity in ODM2, but can be constructed from what is already there. |
|
Hi Jeff,
I endorse the comments you have made. In general, I find ODM2 well thought out, but the problem is a lack of guidance on certain entities such as Taxonomic Classifiers and Variable together. This confusion is showing up in the grab bag of entries in the VariableCV controlled vocabulary. This table needs to be cleaned up with perhaps alternative controlled vocabularies being published for different use cases (ie. biological versus chemical).
In my implementations the TaxonomicClassifiers table is used to describe the "thing" which is being observed, measured, or categorised.
For biological data this is the biological taxa of organism(s).
For geological data this is the mineralogy of the sample.
For ecological habitat data these are the various substrates and micro-habitats being sampled.
I am not sure however how it applies to chemical data - and this seems to be the crux of what Anthony is examining. Perhaps named environmental topological contours demarcating a meaningful context of the sample is what should be used here.
For example, in ocean sampling a common designation of sampled environment relates to depth (ie. Epipelagic, mesopelagic, bathypelagic, abyssopelagic, and hadopelagic) these are meaningful in the context of depth contour experiments across and sampled area).
For groundwater experiments, the sampled zones could be the unsaturated, fringe, and saturated zones.
For soils - horizons A,B, C, bedrock
Going back to geological data - a sample of a specific mineralogy could be analysed for chemical isotopic signatures.
The structure allows for all of this but we need some explicit documentation and proposed controlled vocabulary sets.
What are your thoughts,
Sam
…________________________________
From: Jeff Horsburgh <notifications@github.com>
Sent: Tuesday, October 30, 2018 11:16:07 AM
To: ODM2/ODM2
Cc: Samuel Nelson; Mention
Subject: Re: [ODM2/ODM2] Modify Variables table to enable greater interoperability (#160)
Maybe I'm not following this closely enough, but largely, I think this just reorganizes/moves stuff that already exists in ODM2. It may not all be in the Variables table now, but there's good reasons for why things are where they are.
Why is the suggestion to move the content of the Variable Name CV table into the main Variables table? I see the following comment in this commit (8ad71c4<8ad71c4>):
ODM2CV.CV_VariableName table: Deleted ODM2CV.CV_VariableName table (and also CV_VariableNamenew), as the new approach to Variables does not rely on an internal variable CV, but rather a system for mapping to external variable/parameter term lists.
First, the "CV_VariableNamenew" was never part of the ODM2 schema (not sure where it came from), and second, wasn't the existing VariableName CV already a "system for mapping to external variable/parameter term lists?" It never relied solely on an internal CV and always had the capability to link to terms from other vocabularies. Why break the convention used by all other CVs in ODM2 when it doesn't add new functionality? Users could already link to URIs for externally defined terms via the existing Variable Name CV. How would they do so now - you have a VariableSourceURI, which implies that there is a source out there that supplies all of the information in your proposed new Variables table, and I don't think there is one. So, I'm not sure what interoperability this would bring.
Also - I don't understand why you are suggesting moving Medium into Variables when I think the same arguments you made for keeping other stuff out of Variables (e.g., units) could be made for keeping Medium out of Variables. Wouldn't Medium be a property of the Result (as we had it already) an not a property of a Variable? Temperature is temperature whether it is measured in air or water. Moving the Medium to Variables means that we will be duplicating Variables (now I have to have a variable for temperature in water and another one for temperature in air).
Changing the name of VariableTypeCV to VariableDomainCV seems like an unneeded change. It doesn't really add anything new.
The absence of a VariableCode will not support many use cases where short codes for Variables are commonly used.
QuantityKindCV moves some Units information back into Variables? I know you are proposing that this is equivalent to the UnitsTypeCV, but isn't that a property of Units? It already exists in the Units table that is linked to a Result. I guess I don't really understand how moving it helps.
As @PleiadesAustralia<https://github.com/PleiadesAustralia> notes - there are many variables (particularly biological ones) where the VariableName (e.g., "Count") is qualified by a TaxonomicClassifier (e.g., some species name).
I think this:
Variable = MediumCV term + TaxonomicClassifier term + SpeciationCV term + QuantityKindCV term
Goes beyond what a "Variable" is, is missing what we are now calling VariableName, and introduces a higher level concept that is not represented by a specific entity in ODM2, but can be constructed from what is already there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#160 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AlE2g4nG4sUlLpfiJ6fhTBYeiLvg0kyNks5up8R3gaJpZM4W_v4R>.
|
|
@PleiadesAustralia - your understanding of the original intent behind TaxonomicClassifiers is correct. They were there to further qualify the "thing" that is observed - e.g., if I am observing a "count" of a biological organism, the taxonomic classifier is there to tell me what species I am counting. And, yes, there are other contexts besides biological data where this is useful. There's perhaps a couple of things going on there. First, I think you are right that there isn't enough specificity or guidance on how the existing constructs can be used with existing data use cases. This could certainly improve - and we hoped that it would through use. Nobody on our original team could cover all of the use cases to which these constructs might apply. Second, I think we are constrained somewhat by what we are able to do in a relational database implementation. The information model that describes all of the elements of "what" was measured is sound in ODM2. As @aufdenkampe notes in his description above - the things he's looking at already exist in ODM2. The particular organization in tables as we have it now in the ODM2 blank schemas may not work for every use case. This is not necessarily a deficiency of the information model, but I think there will always be some deficiencies or challenges with physical implementations. |
|
Hi Anthony, Jeff and all,
Thank you for including me on this thread. Let me know if you get this
email as "Reply All" is giving me some strange "noreply" email addresses.
(I also added your emails separately to be on the safe side.)
The CSDMS Standard Names has evolved considerably into the Geoscience
Ontology (or Geoscience Standard Names), see: geostandardnames.org. The
GSN ontology is much more than a controlled vocabulary, and provides a
general approach to standardized, scientific variable names to be used for
automatic semantic mediation in workflows. We use a variety of Semantic
Web technologies and best practices so that everything is available in RDF
and via a SPARQL endpoint. Anthony, you mentioned the "object part" of
the CSDMS Standard Names, and we now have a very general approach to the
"object part" that consists of many components and can handle very general
context and complexity, unlike the CSN approach. Maria Stoica, who works
for me, has done an incredible job of developing a general approach to the
"object part" that can handle even the toughest cases we've come across.
Also, we have mapped all of the NWIS Parameter Code Dictionary long names
(of which the CUAHSI VarName CV is a tiny subset) into our system.
"Standard names" are now "RDF bundles" (or "fully atomized" in the
language of our meeting in Boulder), but we still support "serialized",
single-string versions of them for a variety of applications, including
ease of human recognition and matching.
I am currently funded by DARPA, through its World Modelers program, to
extend our approach to include variable names for the domains of
agriculture, economics and social sciences. We are developing natural
language processing (NLP) and machine-learning algorithms, together with
colleagues, to perform tasks such as "concept refinement" and the
semi-automatic construction of standardized variable names that are
GSN-compliant. If you'd like to get caught up on where we are with all of
this, I could give a webinar or something like that on these developments.
Btw, I don't know what is happening with QUDT, but they have not been
active for some time. Their approach, like ours, is anchored in metrology
and ISO 80000 (International System of Quantities), which is where the term
"QuantityKind" comes from.
Best regards,
Scott
…On Tue, Oct 30, 2018 at 11:10 AM Jeff Horsburgh ***@***.***> wrote:
@PleiadesAustralia <https://github.com/PleiadesAustralia> - your
understanding of the original intent behind TaxonomicClassifiers is
correct. They were there to further qualify the "thing" that is observed -
e.g., if I am observing a "count" of a biological organism, the taxonomic
classifier is there to tell me what species I am counting. And, yes, there
are other contexts besides biological data where this is useful.
There's perhaps a couple of things going on there. First, I think you are
right that there isn't enough specificity or guidance on how the existing
constructs can be used with existing data use cases. This could certainly
improve - and we hoped that it would through use. Nobody on our original
team could cover all of the use cases to which these constructs might apply.
Second, I think we are constrained somewhat by what we are able to do in a
relational database implementation. The *information model* that
describes all of the elements of "what" was measured is sound in ODM2. As
@aufdenkampe <https://github.com/aufdenkampe> notes in his description
above - the things he's looking at already exist in ODM2. The particular
organization in tables as we have it now in the ODM2 blank schemas may not
work for every use case. This is not necessarily a deficiency of the
information model, but I think there will always be some deficiencies or
challenges with physical implementations.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#160 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHU-L32LPOKx2gGZha__wt87-x-7eaHqks5uqGvugaJpZM4W_v4R>
.
|
|
@PleiadesAustralia, Yes! It sounds like from your second comment (#160 (comment)) that you are already using the TaxonomicClasssifiers table exactly as is intended, to be the primary term identifying the object of the "Variable". It in fact works very well when applied to chemical variables, especially given that chemical taxonomies & ontologies are very well defined (with ChEBI being the best for our purposes, as first identified by @dr-shorthair et al.). I fully agree with your suggestion:
Regarding proposed vocabulary sets, I strongly suggest ChEBI and ITIS for chemistry and biological taxonomy respectively. I also know there are 3-4 good soil taxonomies that differ more by region that completeness (so all could/should be used according to need). Do you have recommendations on:
So, given your second comment, I'm not sure how to interpret your first comment (#160 (comment)):
Just as the concept of It is indeed true that under this "model there would be a requirement to register multiple variable for each biological taxa... [which] number in the tens of thousands." The same is true for chemical "species" and "substances". That is why USGS has >8000 parameter codes for water quality, largely because of all the chemical species. This challenge is also why CUAHSI was completely overwhelmed by the number of requests for new terms in their VariableName CV as soon as geochemists started using their system. All of this was the motivation for the numerous workshops mentioned in our our EnviroVariableNames-ODM2TeamIdeas Google Doc. The consensus from all these discussions and workshops was that we should no longer try to maintain variable name controlled vocabularies, but rather find an approach define existing and new variable names to their core concepts. The redesign proposed in this thread is a carefully thought-out response to those needs, and it's based on a lot of conversations. I appreciate your feedback and look forward to more thoughts and questions. |
|
@horsburgh, thanks for your thoughts! Indeed, the proposed modifications mostly moves around existing fields from one table to another. That was the primary intent -- to group concepts that best belong together -- in order to simplify the input of data and increase the power of queries at extracting related data from multiple sources. Such interoperability and data-value-level integration from diverse data sources has always been the primary motivation of ODM2. Back in 2013, when we were developing the ODM2 Variables & Results tables, we did a great job of massively improving those capabilities from ODM1 to ODM2, making great strides toward our goal. However, by early 2014 we already realized several weaknesses in our structures for Variables, but we decided that it time to move forward with imperfection and table those issues. I remember those discussions, reasoning and decisions well; I recently reviewed our extensive notes on it all. The decisions we made at the time were good ones, and I supported them. We now have new knowledge and greater experience to guide a revision to improve ODM2. The current ODM2.0 Variables table is very constraining because it requires that every record is tied to a term from the single, official ODM2 VariableNameCV. Back in 2013 we added flexibility by allowing one-to-many relationships between a user-selected VariableCode and VariableNameCV terms, but still doesn't provide a pathway to use a VariableCode that can't be considered a subset of an existing VariableNameCV term. Also, as described in #160 (comment) above, our consensus from the CUAHSI Ontology Capstone Meeting April 2014 held at CUNY and the May 2016 Environmental Chemistry Names/Ontology Workshop held in Boulder was that we should no longer try to maintain variable name controlled vocabularies, but rather find an approach define existing and new variable names to their core concepts. This proposed ODM2.1 changes are designed to move that idea forward, by:
Most other modifications (primarily field name changes) are relatively non-substantive, but were implemented to improve clarity of understanding, which has long been another high-level goal of ODM2 (which is why we didn't directly adopt most OGC O&M terminology). |
|
@peckhams, thanks for chiming in with your thoughts and an update of how the CSDMS Standard Names effort has evolved into Geoscience Standard Names. From what I can see, the proposed ODM2.1 would interoperate very well with your system, conventions and endpoints, while also allowing existing CUAHSI HIS/ODM1 and ODM2.0 databases a path for forward migration to ODM2.1. That's awesome. I'm looking digging in deeper to figure out how we can leverage this as much as possible, especially for USGS NWIS parameter codes. BTW, although the main QUDT website looks unchanged since 2015 (when we harvested metadata from QUDT r1.1 for our Units and UnitsType/QuantityKind vocabularies (some background at ODM2/ODM2ControlledVocabularies#34), there was progress toward QUDT r2.0 in 2017 (see http://www.qudt.org/release2/qudt-catalog.html). Has the project been dead since then? It would be a shame, since they seemed to be more complete and more on the right track than any other effort. |
|
I am coming back to this conversation after considerable experience with Taxonomic Classifications but have a new quandary. This involves morphology and tissue types off a single biological organism. I am leaning towards expanding my use of the CV_Medium entity. Could a Medium be a Morphology or particular tissue type. I am leaning towards this because this would allow the Results table to be used to compare specific aspects of different species. We could use the Category field to direct the application to particular Groups of species. What do you all think? |
|
@PleiadesAustralia, thanks for reconnecting with this conversation! It's also great that you are returning with greater experience and interest in biological Taxonomic Classifiers. I share your perspective that expanding the Medium CV is key for improving ODM2.1 utility for biological and biodiversity datasets. We've always had much more engagement in ODM2 from geoscientists than biologists and ecologists, and the Medium CV reflects that! I also really like your idea that a massively expanded Medium CV would allow comparisons of specific tissues/morphologies across species. Do you have a recommended or draft list of additional terms? As I mentioned in #160 (comment) above, I'm keen on learning what exists out there. Although in that comment, I guess I was suggesting that maybe those terms would apply to different TaxonomicClassifers (i.e. species), to more easily connect to complex and external systems. I wonder if we might use the SpeciationID for this purpose?, SpeciationID is a second instance of TaxonomicClassifers, which was designed for the chemical use case of describing something like "nitrate expressed in units of *nitrogen". Could we use that for describing the type of tissue, if the tissue taxonomic is complex and external (which I suspect it is). For clarity, a diagram of the new variables portion of ODM2.1, including TaxonomicClassifiers, is shown in #153 (comment) |
|
Hi Anthony,
I found the TRY database of plant traits to be a good standard ref to use for botanical applications (https://www.try-db.org/TryWeb/Home.php) although their trait names would be an amalgam of medium, variables and units. My current database is for seagrass meadow investigations and I found this to be largely applicable.
I’ll have to think carefully about your proposal on SpeciationID. I agree that CV_VariableName is not working (it could but people are semantically overloading it with all sorts of rubbish). I’d like that table to focus on something related to Dimensional Analysis. However, an intersection table between taxonomy and variable could create a significant admin headache. One between Taxonomy and medium could make sense though.
I have heaps of stuff, including a complete Microsoft tools architecture (Office, XML, SSIS, SQL Server) that is tailored for Resource Mamagement agencies. What is the best way to share?
Cheers,
Sam
…Sent from my iPhone
On May 12, 2020, at 8:46 PM, Anthony Aufdenkampe <notifications@github.com> wrote:
@PleiadesAustralia<https://github.com/PleiadesAustralia>, thanks for reconnecting with this conversation! It's also great that you are returning with greater experience and interest in biological Taxonomic Classifiers.
I share your perspective that expanding the Medium CV<http://vocabulary.odm2.org/medium/> is key for improving ODM2.1 utility for biological and biodiversity datasets. We've always had much more engagement in ODM2 from geoscientists than biologists and ecologists, and the Medium CV reflects that!
I also really like your idea that a massively expanded Medium CV would allow comparisons of specific tissues/morphologies across species.
Do you have a recommended or draft list of additional terms? As I mentioned in #160 (comment)<#160 (comment)> above, I'm keen on learning what exists out there. Although in that comment, I guess I was suggesting that maybe those terms would apply to different TaxonomicClassifers (i.e. species), to more easily connect to complex and external systems. I wonder if we might use the SpeciationID for this purpose?, SpeciationID is a second instance of TaxonomicClassifers, which was designed for the chemical use case of describing something like "nitrate expressed in units of *nitrogen". Could we use that for describing the type of tissue, if the tissue taxonomic is complex and external (which I suspect it is).
For clarity, a diagram of the new variables portion of ODM2.1, including TaxonomicClassifiers, is shown in #153 (comment)<#153 (comment)>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#160 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJITNAYGCOZJZWW6Z7DU7WTRRFAJ7ANCNFSM4FX67YIQ>.
|
This issue follows up up on my suggestion in ODM2/ODM2DataSharingPortal#71 (comment) that we pick up the "800-lb gorilla" issue to reimagine variables as we described our EnviroVariableNames-ODM2TeamIdeas.
This directly addresses the semantic overloading challenge that we've all been aware of from the beginning and discussed at the April 2014 CUAHSI Ontology Project Capstone workshop and further developed during the May 2016 Environmental Chemistry Names/Ontology Workshop. Most recently @PleiadesAustralia raised in this "Semantic overloading of CVVariableName" issue: ODM2/ODM2ControlledVocabularies#35.
I've been working with @roelofversteeg and we have an idea on how to move forward that allows us to hang on to older Variable/Parameter terms while also breaking down each term into its semantic/conceptual components in a way that enables both more granular queries and cross-walk mapping.
We'll share soon.
The text was updated successfully, but these errors were encountered: