-
Notifications
You must be signed in to change notification settings - Fork 10
Property:typeOfCollection #255
Comments
Need an appropriate term for "rocks, minerals and meteorites" MineralSpecimen is there as a placeholder till we find a tame geology person to ask. |
In the examples |
Controlled vocabulary? |
Any suggestions on where artefacts like models, casts and moulds would fit into this? Neither ArchaeologicalArtefacts or EthnographicObjects quite seem to work... |
I was thinking these would fall under preservedSpecimen but I see your point that these may also be related to archaeological or ethnographic objects. They might deserve a new category as they seem to have fairly different characteristics (so probably different dimensions needed to describe them). They are 'indirect evidence' and also that they have some reproducibility, copies of them can be made. Something like InferredSpecimen? There are other objects as well which I would put under preservedSpecimen but are a little problematic: specimen constructs, like bird nests. |
I'm inclined to avoid 'specimen', as that term indicates a natural origin. Maybe something like ArtificialObjects? Oxford Languages definition of 'artificial' being 'made or produced by human beings rather than occurring naturally, especially as a copy of something natural', seems quite appropriate. As it's quite a broad term though, that does raise the issue that ArchaeologicalArtefacts and EthnographicObjects could be considered subtypes of it, from more specific origins. |
MaterialSamples are NOT only a result of environmental samples! They can be single organism tissues or genomic DNA as well! see definition of GGBN term materialSampleType for clarification: https://terms.tdwg.org/wiki/ggbn:materialSampleType |
Wouldn't it make more sense to extend the existing vocabulary of basisOfRecord? This really seems to be a duplication otherwise. |
we have included "MineralSpecimen" in ABCD3.0 as we also needed a term for the geo community, the ABCDEFG team was quite happy about it :) |
We should add a term for collections that are Digital only (that have no physical specimen associated). Examples: audio or video recordings, digital photogrammetry representations of trackways, 3D serial section datasets of fossils (fossil is destroyed in the process of creating digital object). |
I would say we should not try to extend the existing vocabulary of basisOfRecord! Given that the 'basis' part of basisOfRecord has led to so many different interpretations, and all the other issues with it, it is unlikely that basisOfRecord is continued in future DwC versions, see also tdwg/dwc#302 and https://discourse.gbif.org/t/basisofrecord-for-plazi-datasets/2238. Also, for BoR different vocabularies are in use, which one to take? (GBIF using a different one from DwC: https://gbif.github.io/parsers/apidocs/org/gbif/api/vocabulary/BasisOfRecord.html). |
My geologist says that MineralSpecimen would be OK but prefers RockSpecimen "because fundamentally all rocks are composed of minerals and/or fossils and/or derivative byproducts from natural processes. Meteorites are a type of rock. 99.99% of mineral specimens are not monomineralic, but rather are rocks that are dominated by a particular mineral, or on which a mineral has grown, or is pedestaled, or the like..." |
I propose to change the property name to: CollectionDiscipline. This is primarily to define what can be expected in terms of data (a geological specimen has other data than a botanical specimen), and for a digital specimen can be used as subtypes of a specimen. It matches with the developments in Synthesys+ and avoids confusion with description of physical appearance like digital vs physical, what to do with moulds, birds nests etc. These can be described by what is called 'materialType' in MIDS, probably not the best name as confusing with 'material' (gold, aluminium etc), but something like MaterialAppearance. currently we call it MaterialType. suggested controlled vocab with DwC and ABCD comparison: proposed term - DwC Basis of Record term - ABCD Unit termAnthropology | PreservedSpecimen | - for discussion to decide if mycology should be a separate subtype. In Synthesys we decided not needed. Does it need data elements very different from botany? Geology might need to be separated in minerals and rocks if these are different disciplines recording different data elements. |
Note that in a specimen bulk data refinery use case, for input you would like to know the materialAppearance (should images be expected of a macrofossil, a herbarium sheet or a jar with alcohol? for output you would like to know collectionDiscipline (what data can be expected to be extracted from the images - stratigraphy, taxonomic identifications, a location in the sea?) |
Cultures are LivingSpecimens |
Renamed to typeOfCollection as per recent discussions |
Hi, as members of SPNHC's Biodiversity Crisis Response Committee, a small group of us has the goal of improving regional diversity and representation within the committee and SPNHC. We were excited to discover GRSciColl (https://www.gbif.org/grscicoll) and decided to use it as tool for our networking. At this point of time, we plan to only collect basic and contact information. With all the activities towards COP15 and post-2020 monitoring we seem to be just right in time; for the standard, we come a bit early. Thus, we want to ensure that the information, which we collect now will still be valid once GRSciColl expands and adopts the CD standard. One information that certainly is of interest is which "Disciplines" or organisms/specimens can be expected to be found in the recorded institutions and collections. Browsing CD's GitHub repository, the above vocabulary that @wouteraddink provided (#255 (comment)) is what I would like to know first and foremost: Where are mycological collections that might house specimens of the lichenized ascomycete genus/family I am interested in? Or: Which taxonomic groups/work areas are covered by collections in a specific country or region? Thus, this information is of interest to be collected already now, even if I am not quite sure with which of the currently used fields in GRSciColl to connect it (eg. Institution/Disciplines or Collections/ContentType?). Though, it is of importance that the vocabulary is ok. I am going to propose a modified version of the vocabulary below. All lists that I have seen so far, seem to mix properties. Accordingly, I am not sure about the differentiation of some of the currently existing fields in GRSciColl, eg. Institution/Type, Institution/Institutional Governance, Institution/Discipline, Collection/ContentType. Is there a place for discussion of such a more general question? Unfortunately, I am still not quite certain about the current data structure of CD, which might answer this question. Thanks a lot for your pointers. |
Here a slightly modified list for the vocabulary proposed by @wouteraddink <style> </style>
resulting in 0 | VIROLOGY_LIVING I am not quite sure, about mixing in "living" and "preserved" into this field, however, they integrate well with the "botanical garden" & "herbarium" distinction in botany. I have an alternative structure, which brings me to my question above. As an (ex) lichenologist, I will argue for keeping mycology. Reasons are that the botany and mushroom/lichenological/fungal (ascomycetes) communities are quite separate. Also, preserved mycological specimens are stored not only pressed and mounted on sheets, but more often in folded paper packets or boxes, quite distinct from botany. Virology is alien to me - apart from the effects of certain strains. Viruses are cultured in cell lines, yes-no -> thus part of "culture collections"? Is there a distinction between living/preserved collections? |
Having had troubles to define fields for basic summary information about institutions/collections/organizations, I am currently seeing five fields: GovernanceFunding, Disciplines, Functions, LiveMaterial, OrganizationRole with the following vocabularies. Since these complement and in part explain each other, I am listing them here: GovernanceFunding (field in GRSciColl, terms modified) Disciplines (see examples at Property:Discipline, #320 and this issue here) Functions (based on https://grid.ac/pages/policies vocabulary, modified) LiveMaterials (see this thread) OrganizationRoles since different organizational units might have different roles, alternatively InstitutionRoles (based on NCD vocabulary for InstitutionType, https://tdwg.github.io/ontology/ontology/voc/InstitutionType.rdf) What do you think? Could this make sense and be usable? Any feedback is very much appreciated. |
Some of you know me, though I recognized that my nick doesn't easily resolve: Jutta Buschbom, Statistical Genetics, Germany. As part of the Regional Groups/Diversity working group of SPNHC's Biodiversity Crisis Response Committee, we would very much appreciate you feedback and insights. Thanks a lot. |
One suggestion. I have a rule of thumb regarding the use of the term 'Other'. It presents significant challenges, but always produces better results. The light version of the rule is "If one of the values is 'Other', then the term needs to be reconsidered". The more stringent version is "If a value is Other, then the term is wrong". There are always exceptions, but 9/10 it holds. There has got to be a better way to achieve the goal of defining organization-level attributes. Easier said than done. |
The term |
For future reference: the Material Sample group has its own github issues to define some of the attributes of this property: http://rs.tdwg.org/dwc/terms/MaterialSample
http://rs.tdwg.org/dwc/terms/FossilSpecimen
http://rs.tdwg.org/dwc/terms/PreservedSpecimen
http://rs.tdwg.org/dwc/terms/LivingSpecimen
|
* Adds hasObject properties to termlist and updates examples * Adds datatypes to termlist * updates identifier to identifierValue * adds Event.eventName * specifies array item datatypes * add range & class-level-properties * Updates Person.Identifier examples to have more than one * Create ltc_skos_mapping.csv Initial version of skos mappings * Create Latimer Core browser.pbix New version of LtC browser * Update Latimer Core browser.pbix Changed skos mapping csv source from local to GitHub * Update Latimer Core browser.pbix Minor fix to property html * Update ltc_standard_terms_draft.csv Added term_status, term_added and term_modified * Update ltc_standard_terms_draft.csv Added proposed hasSchemeTerm and hasSchemeMeasurementOrFact properties to the CollectionDescriptionScheme class * Update ltc_standard_terms_draft.csv Added proposed hasObjectGroup property to CollectionDescriptionScheme class * Update ltc_standard_terms_draft.csv Removed objectClassificationParent property, as superseded by the hasObjectClassification property * Update ltc_skos_mapping.csv Tweaks to some mapping relations, and also removed duplicate rows (repeated for hasIdentifier etc in mulltiple classes) * Update ltc_standard_terms_draft.csv Updates from SKOS mapping review (see issues #399 to #412) * Updates json schema and examples: removes objectClassificationParent and renames Identifier.source as .identifierSource * updates schema description * Adds PersonRole.hasMeasurementOrFact * Fixes omission of parent class in termlist.csv * Updates termlist and schema * Adds term to termlist.csv * Updates StorageLocation schema to include locationDescription * Adds ObjectGroup.alternativeCollectionName to termlist. * Adds ObjectGroup.alternativeCollectionName to ObjectGroup schema and example files * Fixes a couple of typos * adds object count estimates to orgClass * Separates property datatypes from normative termlist fields * Updates bool property names in class-level examples * Updates bool property names in json schema files * Updates bool property names, labels and defs * Small, pedantic edits to definitions to match those in the termlist * updates collectionDescriptionScheme term name to hasCollectionDescriptionScheme * Adds GO terms to skos mapping * Adds GO terms to termlist * Adds GO terms to datatypes list * Adds GeographicOrigin.ecoRegion * Updates json schema with amended definitions for GeoOrigin terms * Update ltc_standard_terms_draft.csv Fixed some special character encodings * Update Latimer Core browser.pbix Refreshed data from termlists * kw-csv-to-json (#432) * setup csv-to-json in tools * setup json-schema converter * add first batch of test-output * draft update 'required'/minItems for arrays * add env options for live/test output * add initial test-output * fix link? * update how-to * edit trouble-shooting + to-do * generalize variable names * fix link * fix name * fix description * typo * reorganize * fix link * update minItems/requirements & troubleshooting * auto-json (#433) * fix MeasOrFact * note date-datatype (to-do) * update main json-schema * Revert "auto-json (#433)" (#439) This reverts commit d881331. * Add spec csv-to-json tool (#440) * add test-spec based on ltc terms CSV * edit test-spec based on ltc terms CSV * add SPEC_CSV variable to .env * add spec script + output path * require CollStHis:hasMeasOrFact and GeoCtxt:bed * fix spec script's use of spec-csv * revert to pre-auto JSON * fix repeatable term vs class * fix SPEC_CSV example URL * add spec JSON_OUTPUT_PATH * add missing spec-steps * fix typo * re-try auto-generating json-schema (#441) * Update ltc_standard_terms_draft.csv Fixed mislabeled measurementAccuracy term * Added Role class Added the new Role class, removed PersonRole.role and added hasRole, with some tweaks to PersonRole class notes * Updated Role mappings and datatypes Also modified PersonRole.hasRole to repeatable array * Adds country codes to examples field * add note to Address.addressCountry field relates to #455 * Update to notes field: only for paleo OGs #465 * Updated examples to "`MaterialEntity`, `InformationArtefact`, `AbstractConcept`" #463 * Removes contactDetailType and adds additional examples to contactDetailFunction * Adds ContactDetail.contactDetailFunction * Update of typeOfCollection? #463 * Adds ObjectClassification.isTopParent * Adds hasParentEvent to Event * Updated typeOfCollection #463 * Update ltc_standard_terms_draft.csv * Corrects required/repeatable flags for ObjectGroup.alternativeCollectionName * baseTypeOfCollection: change from term to terms in def #365 * Updated typeOfCollection example from "MaterialEntities" to "MaterialEntity" #255 * Update typeOfCollection examples * Updated objectType #304 * objectType: example update #304 * objectType: removed spelling error #304 * Updated preparationType Examples and Notes * Updated Examples of preparationType #64 * Changed examples of material #261 * Corrected spelling mistake in material #261 * Updated examples for preparationType #64 * Updated Notes and Examples of preservationMethod #65 * Update to Notes in baseTypeOfCollection #365 * rename CollectionDescriptionScheme ...to ObjectGroupDescriptionScheme - #429 * rename CollectionDescriptionScheme ...to ObjectGroupDescriptionScheme - #429 * rename remaining CollectionDescriptionScheme to "ObjectGroupDescriptionScheme" - #429 * baseTypeOfCollection: set repeatable = YES #446 * Updated baseTypeOfCollection: spelling error #446 * rename to LatimerCoreScheme following #476 & updated #429 * Update ltc_standard_terms_draft.csv Updated according to issue #462 * Update ltc_standard_terms_draft.csv Updated with additional notes from issue #450 * rename baseTypeOfCollection ...to baseTypeOfObjectGroup - #477 * rename typeOfCollection to typeOfObjectGroup - #478 * rename to LatimerCoreScheme - #429 #429 * rename baseTypeOfCollection - #477 to baseTypeOfObjectGroup * rename typeOfCollection - #478 to typeOfObjectGroup * rename typeOfCollection - #478 to typeOfObjectGroup * rename CollectionDescriptionScheme - #429 to LatimerCoreScheme * Add files via upload Terms defined as human versus machine readable. Check terms after all review updates are made. * update LtCScheme in ranges - #429 * rename CDScheme to LtCScheme - #429 "CollectionDescriptionScheme" class name updated to "LatimerCoreScheme" * rename typeOfCollection in ltc.csv - #478 ...to typeOfObjectGroup * rename baseTypeOfCollection in ltc.csv - #477 ...to baseTypeOfObjectGroup * Updated GeographicOrigin to GeographicContext * Update ltc_standard_terms_draft.csv Further updates to definitions in the renamed GeographicContext class * Updates class-level notes and usage recommendations * Removes reference to stratigraphy from verbatimChronometricAge * Update ltc_standard_terms_draft.csv Changed labels for stateProvince and county #431 * Update ltc_categories.csv Updated GeographicContext name & definition * Updated hasOrganisationalUnit to hasParentOrganisationalUnit * updates examples for chronometricAgeProtocol * updates baseTypeOfObjectGroup to array * updates usage notes for isDerivedCollection * update CDScheme to LtCScheme in termlist-header * Updated example for Reference.referenceDetails #454 326 * 2nd Example added for Reference.referenceDetails #326 * Updated example: collection dynamics to growth status #367 * Updated example #124 * Removes collectionDescriptionPID and adds recommendation to hasIdentifier * extends TemporalCoverage to PersonRole, changes dates to datetimes * Update ltc_standard_terms_draft.csv added superGroup property * Updated referenceText to referenceName Closes #453 * Changed collectionName to required = No Closes #485 * Updates GeographicContext.ecoRegion notes * Update ltc_datatypes.csv Updated remaining references to GeographicOrigin to GeographicContext * Added new EcologicalContext class Add class and term definitions * Update ltc_standard_terms_draft.csv Removed ResourceRelationship.resourceRelationshipID as superseded by hasIdentifier * Update ltc_standard_terms_draft.csv Removed GeographicContext.salinityType as superseded by EcologicalContext class * Update ltc_standard_terms_draft.csv While checking boolean values: for "isDistinctObjects" removed "If isDistinctObjects is set to 'true', then no collection object should be covered by more than one object group within the LatimerCoreScheme." from "Usage", since it was already present in "Notes" and fits better there. * Update ltc.csv changed 1 of 11 instances of Organization... to Organisation. The other 10 are from other standards. * Update ltc_standard_terms_draft.csv 2 of 4 instances of "organiza..." replaced with "organisa..." The other 2 are namespace dependent. * match readme to master to prevent conflicts * Update Latimer Core browser.pbix Refreshed from term list, added icon and other minor tweaks * Refreshed derived csvs fpr terms Regenerated namespace-specific CSVs and category CSVs from main term CSV * clean up examples in ltc_standard_terms_draft.csv * Update Latimer Core browser.pbix * Added SKOS mapping decision tree * Term updates from new SKOS review Tweaks to terms to get definitions in line with the outcomes of the new SKOS mappings review. Includes namespace changes and definition tweaks. Also added new StorageLocation.hasParentStorageLocation term. * Update ltc_standard_terms_draft.csv Fix to hasParentStorageLocation term name * Update ltc_standard_terms_draft.csv Removed escaped double quotes * Update ltc_standard_terms_draft.csv Removed unpaired double quote * Update ltc_standard_terms_draft.csv * Update ltc_standard_terms_draft.csv * Update ltc_standard_terms_draft.csv * Updated term mappings Updated SKOS mappings after review and replacing term names with URIs. Added more comprehensive SSSOM mappings. * Removed trailing CSV columns * Update Latimer Core browser.pbix Refreshed data and modified to accept SKOS mappings from URIs * Update ltc_standard_terms_draft.csv Fixed issues with merge overwriting changes * Update Latimer Core browser.pbix Refreshed data --------- Co-authored-by: Kate Webbink <[email protected]> Co-authored-by: Matt Woodburn <[email protected]> Co-authored-by: jbstatgen <[email protected]> Co-authored-by: fmjjones <[email protected]> Co-authored-by: Sharon Grant <[email protected]> Co-authored-by: Kate Webbink <[email protected]>
PreservedSpecimens
,FossilSpecimens
,MineralSpecimens
,ArchaeologicalArtefacts
,EthnographicObjects
,HumanRemains
,HominidRemains
,MaterialSamples
,LivingSpecimens
The text was updated successfully, but these errors were encountered: