Change term - organismQuantity

[tucotuco]

Change term

• Submitter: John Wieczorek
• Justification (why is this change necessary?): Clarity
• Proponents (who needs this change): Everyone

Current Term definition: https://dwc.tdwg.org/list/#dwc_organismQuantity

Proposed new attributes of the term:

• Term name (in lowerCamelCase): organismQuantity
• Organized in Class (e.g. Location, Taxon): Occurrence
• Definition of the term: A number or enumeration value for the quantity of organisms.
• Usage comments (recommendations regarding content, etc.): An organismQuantity must have a corresponding organismQuantityType.
• Examples: 27 (organismQuantity) with individuals (organismQuantityType). 12.5 (organismQuantity) with %biomass (organismQuantityType). r (organismQuantity) with BraunBlanquetScale (organismQuantityType). many (organismQuantity) with individuals (organismQuantityType).
• Refines (identifier of the broader term this term refines, if applicable): None
• Replaces (identifier of the existing term that would be deprecated and replaced by this term, if applicable): http://rs.tdwg.org/dwc/terms/version/organismQuantity-2017-10-06
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): not in ABCD

This proposal is to add the example of "many" and an organismQuantity to complement the proposed usage comment under individualCount (see Issue #285).

[baskaufs]

dwciri: analog analysis for this proposal:

OK, with respect to my comment on the organismCount proposal, I see here that "many" is actually included in the examples here.

I went to the RDF guide for guidance, but discovered that organismQuantity and organismQuantityType are not to be found anywhere in the guide. Aaaaargh! How did we miss that? These terms date originally to December 2014 and March 2015, while the RDF Guide was adopted in March 2015. All I can figure out is that the organism quantity terms were being considered at the same time as the Guide (whose ratification dragged on for over year as I recall). So I guess they just slipped through the cracks.

Honestly, I am at a loss as to how to properly model these two terms in the RDF/dwciri: space. I think that some kind of controlled vocabulary would be required, but given that the possible values are a mix of numeric literals and concepts (like "many" or "r in the BraunBlanquetScale") that would be pretty messy.

@tucotuco what do we do here? Obviously these terms did just fine for almost a decade without dwciri: analogs or a way to represent them in RDF. Do we just leave that situation as is and add a note in the RDF Guide that we currently don't know how to represent them in RDF just like we did for the ResourceRelationship terms? That's kind of a cop-out, but given the complexity here, I don't see a better solution without one or more people putting some effort into figuring out how to best model this in RDF. Given how busy everybody is, I don't see that happening on the timescale of ratifying this proposal.

[rukayaj]

The addition of "Many" doesn't really cover the range/estimate use case, i.e. if organismQuantity is give as 0-5, etc as in gbif/portal-feedback#767 . Is best practice to use measurementOrFact instead?

[tucotuco]

@rukayaj The way the term is defined, a range is not a valid use. That doesn't mean that there isn't a valid use case for ranges, it just means that the definition would need to be changed, which has much stricter requirements for consideration and acceptance. If you want to go that route, the first step would be to rally independent stakeholder organizations who need to share or consume such data or both. This is to demonstrate that the demand requirement is met (something that is not needed in order to make just a clarification, which is all this proposal is for currently). There are two existing alternatives for sharing ranges of values for this concept. One is using MeasurementsOrFacts, which would require an extension with two rows per Occurrence, one with the equivalent of a minimumIndividualCount and one with the equivalent of maximumIndividualCount. The second way would be to include the information in the Occurrence record itself with no extension using dynamicProperties, with a value such as {"minimumIndividualCount":0, "maximumIndividualCount":5}. Doing it in either of these ways takes informal advantage of the definition of the individualCount term, which is more apt than organismQuantity here because the quantity type (individuals) is inherent in the definition, unlike organismQuantity, which requires the organismQuantityType in order to be understood.

[tucotuco]

@baskaufs We have a similar issue with sampleSizeValue and sampleSizeUnit. Is there a precedent we can take from the treatment of MeasurementsOrFacts in the RDF Guide, or simply recommend that these Value:type pairs only be encoded as MeasurementsOrFacts in RDF?

[baskaufs]

@tucotuco I think at this point maybe we should defer on making a recommendation until there is some broader review of the RDF guidelines.

[EstebanMH-SiB]

From the user approach could be valid to use "many" as a description of the number of observations.
However, we fear that the presence of that example promote the use of "many" instead of a more informative numeric estimation.
"Many" could be interpreted for some people as "two or more" and is difficult to explain the cases in whish this option is valid to use. We consider "Uncountable" a better option as a vocabulary.

We made this comment in behalf of @SiBColombia

[tucotuco]

@EstebanMH-SiB I understand your point, however, I don't see that 'uncountable' achieves anything that 'many' does not. In addition, they might have been countable but were not counted. Would 'multiple' to denote at least more than one be satisfactory instead? The point of the example is to show that non-numeric values for individuals can be used here unlike for individualCount.

[RicardoOrtizG]

@tucotuco In this case, "many" seems a better option than "multiple". We agree with the example.

[tucotuco]

Done.