Closed tucotuco closed 3 years ago
I would like to see a definition of chronometric age somewhere in the documentation (e.g., in abstract; introduction) as the existing definitions used are circular (defining the term using the term). See https://onlinelibrary.wiley.com/doi/pdf/10.1002/9780471915256.app2 for ideas.
Thanks @gkampmeier. Would something like the following suffice within the abstract?
"The Chronometric Age Vocabulary is standard for transmitting information about chronometric ages - the processes and results of an assay used to determine the age of a sample. This document lists all terms in namespaces currently used in the vocabulary."
Yes, @tucotuco that helps. Thanks!
Is there a mechanism to supply IRI values for chrono:chronometricAgeDeterminedBy, either with an id term chrono:chronometricAgeDeterminedByID or an IRI namespace chronoiri:chronometricAgeDeterminedBy? Such a mechanism would be needed to allow an RDF representation to express a list of chronometric age determiners as repeated id terms, each pointing to a determiner agent by ORCID or other agent identifier.
I see the statement "Once ratified, the Darwin Core RDF Guide will be updated to include the IRI versions of appropriate terms from this vocabulary, in the chronoiri: namespace, for use in RDF (e.g., as Linked Open Data)." in the issue above, however, this feels like something that should be an explicit part of the chrono vocabulary, not relegated to the RDF guide, and some possible future action on the RDF guide.
In the definition of chrono:ChronometricAge "The age of a specimen or related materials that is generated from a dating assay.", the word "related" worries me a lot, particularly when combined with some of the example values "stratigraphically pre-1104" "Double Tuff". This implies that related means stratigraphically correlated, which extends to pretty much any fossil placed within any chronostratigraphic unit. This definition allows the term to be used with any dwc:geologicalContext to provide a date range for that geological context, rather than reporting on dates directly derived from samples, which I understand to be the intent of this proposal. I'd be much happier with either (1) the term being restricted to application to a material sample, with the removal of "related material", or (2) the explicit expansion of the vocabulary to include correlation, with a term that allows the assertion of whether a chronometricAge is derived directly from the material sample, is derived from a material sample in the same continuous section/exposure/core, or whether the age applies by stratigraphic correlation (probably with discussion of how to handle specimens identified to taxa that define biostratigraphic zones), or (3) an explicit statement that related applies only within a single continuous section/exposure/core, and a term that distinguishes between dates obtained from the material sample itself, or from another material sample.
As an environmental archaeologist I'd interpret 'related materials' to include the sediment sample which included the macrofossils (insects, seeds, pollen etc). With the exception of bones, recording of the exact material dated is often missing, especially in legacy data, so dates are generally on samples and not specimens in the databases. Whether and how the specimens and the sample are actually correlated is often missing information, and many samples are fuzzily dated relative to archaeological contexts or artefacts. However, suggestion (1) appears to work in this context. From my perspective suggestion (2) sounds useful, but will generally be blank for most of our datasets (unless anyone can fund someone to look it all up!). (3) Probably doesn't work for many archaeological excavations, which can be a mess.
Apologies for butting in here! I'm monitoring this discussion as we are intending to use the extension to feed data from www.sead.se into https://biodiversitydata.se/.
It feels like the example for chrono:materialDatedID should use a materialSampleId instead of an occurrenceID. The material which was dated was not an occurrence, but a material sample. Consider a set of radiometric dates made from samples of tree rings from a core of a long lived tree, correlated by tree rings to a burned log found in a midden, clarity of what got dated how requires reference to the material sample that was dated. In RDF, linking through materialDatedID to an occurrence instead of a material sample is likely to lead to confused inferences about the related occurrence. I'm inclined to think that this goes beyond the example, and the definition of the term should be explicit about it relating to a material sample, not an occurrence. materialDatedID also indicates that chrono and chronoiri need to be explicitly brought into and dealt with within the chronometric age vocabulary. chrono::chronometricAgeDeterminedBy, chronoiri::chronometricAgeDeterminedBy, and chronoiri:materialDatedID (but no chrono:materialDatedID), sound like they need to be explicitly discussed in the vocabulary. There are likely chronoiri terms that can relate to time: terms (time:timeTRS, thors;ReferenceSystem, time:interval, time:instant, etc), e.g. chronoiri:maximumChronometricAgeReferenceSystem/minimumChronometricAgeReferenceSystem might relate closely with time:timeTRS and thors:ReferenceSystem (or not, I haven't looked closely - but more attentions needs to be given to potential chronoiri terms and their definitions).
Makes sense to map dates to samples rather than occurrences to me. Although for mapping to GBIF we have to use occurrenceID's for every instance of a taxon, and thus in our export we will have to derive the dating information for every occurrence from the sample in which it was found. This will inevitably be a compromise, as many samples have many (forms of) dates, the resulting age range will be the min and max of these with information on how they were derived. (If this information is out of context just ignore me!)
We've been using this for the FuTRES metadata template and it is working well for paleontological and archaeological data. I like the idea of relating it to the class materialSampleID as if related materials are sampled it's important to distinguish that from the specimen, which is tied to the occurrenceID.
I have added a change term request that I think is sufficient to take care of the issue raised about materialDatedID pointing to a MaterialSample. If there is further discussion on that solution, let's take it to that issue. There remain other issues from the discussion so far about IRI terms. I'll try to comment or make a separate issue for those as soon as I can. [Added note: these have been created at issues #18 and issues #21.
I have opened an issue to cover the IRI term concern about chonometricAgentDeterminedBy. Please follow the commentary there.
I have opened an issue to cover the question of the treatment of IRI terms in the RDF Guide versus elsewhere. Please follow the commentary there.
When discussing geologic time, the terms maximum, minimum, upper, and lower may be confusing to non-geologist informatics personnel tasked with mapping data onto an exchange schema. It may be advisable to include oldest and youngest in the definitions for maximumChronometricAge and minimumChronometricAge instead of, or in addition to upper and lower.
When discussing geologic time, the terms maximum, minimum, upper, and lower may be confusing to non-geologist informatics personnel tasked with mapping data onto an exchange schema. It may be advisable to include oldest and youngest in the definitions for maximumChronometricAge and minimumChronometricAge instead of, or in addition to upper and lower.
Would usage comments be sufficient to cover this, or is it necessary to be in the definition?
I have opened an issue to cover the question of what the ChronometricAge refer to. Please follow the commentary there.
I have separated out two issues from one of the comments of @chicoreus above, one for the materialDatedID term and one for ID terms vs IRI terms. Please use those issues to continue those discussions.
@tucotuco in reference to oldest/youngest:
Would usage comments be sufficient to cover this, or is it necessary to be in the definition?
By analogy to (and for consistency with) the dwc:gGeologicalContext terms, where earlyest and latest are used in the definitions for terms which can take temporal concept values "latest possible geochronologic", "earlyest possible geochronologic", the normative definition feels like the place to do this, and for consistency earlyest and latest may be the words to use instead of oldest and youngest.
I have added a change term request for the suggestion to clarify that maximumAge refers to the oldest age and minimumAge refers to the most recent age. If there is further discussion on that solution, let's take it to that issue.
It looks like all the concerns I raised have been dealt with in the related issues, except for #20 where I still have concerns about "related".
All issues resolved in public review.
Ratified! Closing.
Introduction
The ChronometricAge Task Group of the Earth Sciences and Paleontology Interest Group has prepared a vocabulary enhancement for Darwin Core consisting of a ChronometricAge class and its properties. Unlike previous term change or addition proposals for Darwin Core, this proposal is for a complete package of terms meant to act as an extension to Darwin Core, enabling Darwin Core Occurrences to be enriched with one or more ChronometricAge records. Also unlike previous proposals, the extension has its own separate (this) Github repository and the terms in the extension have their own namespace (
chrono:
). Documentation for this extension follows the same pattern as Darwin Core, with a separate normative term list (human and machine readable) and a human-friendly Quick Reference Guide. Though the documentation is separate from Darwin Core in this way, the extension will be managed by the Darwin Core Maintenance Interest Group and supported via the Darwin Core Questions & Answers site. Once ratified, the Darwin Core RDF Guide will be updated to include the IRI versions of appropriate terms from this vocabulary, in thechronoiri:
namespace, for use in RDF (e.g., as Linked Open Data).What to do
The purpose of this GitHub issue is to capture and respond to feedback during the minimum 30-day open public commentary period, starting 2020-11-21. Public commentary is part of the process of making changes to an existing standard, as described in the TDWG Vocabulary Maintenance Specification. Please use the "Comment" feature at the bottom of this issue to share your thoughts. If for any reason you can not or do not wish to comment here, it is also acceptable to send a message to the tdwg-content list (tdwg-content@lists.tdwg.org), or feel free to send a message via email to the Task Group Convenor (gtuco.btuco@gmail.com). If you use the latter option, please indicate what part of the content of the message can be shared here on your behalf.
Reviewing the extension:
Other pages of interest: