dwc
dwc copied to clipboard
tdwg
Change term - associatedSequences
Change term
- Submitter: John Wieczorek
- Justification (why is this change necessary?): Consistency and clarity
- Proponents (who needs this change): Everyone
Current Term definition: https://dwc.tdwg.org/terms/#dwc:associatedSequences
Proposed new attributes of the term:
- Term name (in lowerCamelCase): associatedSequences
- Organized in Class (e.g. Location, Taxon): MaterialSample
- Definition of the term: (unchanged): A list (concatenated and separated) of identifiers (publication, global unique identifier, URI) of genetic sequence information associated with the MaterialSample.
- Usage comments (recommendations regarding content, etc.): Note that the ResourceRelationship class is an alternative means of representing associations, and with more detail. Recommended best practice is to separate the values in a list with space vertical bar space ( | ).
- Examples:
http://www.ncbi.nlm.nih.gov/nuccore/U34853.1,http://www.ncbi.nlm.nih.gov/nuccore/GU328060 | http://www.ncbi.nlm.nih.gov/nuccore/AF326093 - 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/associatedSequences-2017-10-06
- ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): DataSets/DataSet/Units/Unit/Sequences/Sequence/ID-in-Database + constant
Discussions around changes to relationshipOfResource (#194), around a new term relationshipOfResourceID (#186, #283), and changes to associatedOccurrences (Issue #324) suggest that a clarification should also be made in the associatedSequences usage notes. Specifically, the convention on list item separation and the reference to ResourceRelationship as an alternative means of capturing these data are recommended.
dwc:associatedSeqences does not have dwciri: analog, so no revision necessary in that namespace.
Related issues are Issue #1, Issue #3, Issue #24 (reopened because of renewed interest), Issue #314, Issue #344, Issue #345, Issue #346, and Issue #347.
The Australasian Herbarium Information Systems Committee (HISCOM) considers moving attributes from Occurrence to MaterialSample premature given the Extended and Digital Specimen consultation that is occurring and the general conversation about the definition and scope of MaterialSample (#314).
Relates also to associatedSequences (#332), preparations (#346) and disposition (#347)
Regarding the usage note, associatedSequences differs from associatedOccurrences, associatedTaxa etc. In that it takes a list of URIs rather than a list of key–value pairs, so using the ResourceRelationship class instead does not add anything and in fact might make it harder for consumers to interpret and for aggregators to process the data. We suggest removing this usage note.
We endorse this proposal for the change in usage comments on behalf of @SiBColombia. We think that the change in the class is also logic, but maybe is better to wait for the results of the consultation as @afuchs1 proposses, just to be sure.
The Australasian Herbarium Information Systems Committee (HISCOM) considers moving attributes from Occurrence to MaterialSample premature given the Extended and Digital Specimen consultation that is occurring and the general conversation about the definition and scope of MaterialSample (#314).
In the case of a sequence, it necessarily must derive from a MaterialSample, so I see no risk in making that organizational change regardless of the Extended and Digital Specimen consultation. Can anyone realistically see any risk in this non-normative change for this term?
Relates also to
associatedSequences(#332),preparations(#346) anddisposition(#347)Regarding the usage note,
associatedSequencesdiffers fromassociatedOccurrences,associatedTaxaetc. In that it takes a list of URIs rather than a list of key–value pairs, so using the ResourceRelationship class instead does not add anything and in fact might make it harder for consumers to interpret and for aggregators to process the data. We suggest removing this usage note.
The usage note does not even make the recommendation to use ResourceRelationship instead, it only points out that it is an alternative, which is still true, including that more detail can be added (contrary to the position that "it does not add anything"). Would a change in the usage note from "Note that the ResourceRelationship class is an alternative means of representing associations, and with more detail" to "Note that the ResourceRelationship class is an additional means of representing associations, and with more detail" alleviate the perception that the ResourceRelationship representation is somehow preferred?
This proposal has been labeled as 'Controversial' and in need of a task group to for resolution. It is no longer part of an active public review.