You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a contradiction between the definition of this term and the way it is displayed in the ER diagram. In the diagram, each ods:Identification has only one ods:TaxonIdentification, whereas according to the definition here, it can have multiple.
From our perspective it makes more sense to only have one TaxonIdentification connected to the Identification class, as the DigitalSpecimen could have multiple Identifications. The way it is set up, the Identification says who did the identification and when and the taxon identification is the result (there could other identification types in the future, e.g. for geological identifications). Having a second result to the same identification event, doesn't really make sense and in the rare cases where this might be useful, it can also be modeled as two separate identifications by the same person on the same date.
If this is adjusted and only one TaxonIdentification is allowed per Identification, then the term needs to be renamed to be aligned with the naming convention, which would be TaxonIdentification. If the changes proposed in #169 are accepted, then the name can remain as it is and the term only needs to be adjusted in with its structure and definition.
The text was updated successfully, but these errors were encountered:
Hi David, thanks for this comment.
As with a lot of the openDS, we have looked closely at what others are doing.
In this case, this structure is based on what Arctos has implemented and what has been proposed for the GBIF UM.
See the explanation of John Wieczorek in this video starting at minute 18:00.
His example shows a parka made out of the fur from several species.
The parka has a single identification which contains multiple taxonomic identifications (one for each species).
The identification moment was one moment in time by a particular actor, resulting in one accepted identification.
Splitting this up in multiple identifications, all with one taxonomic identification, would misrepresent reality.
It would also suggest that there are multiple competing identifications, of which only one can be the accepted identification.
Therefore, I suggest we keep the array of TaxonIdentification, although this will often consist of just one instance.
Term Name
ods:hasTaxonIdentification
Digital Object Name
DigitalSpecimen: Identification
Feedback
There is a contradiction between the definition of this term and the way it is displayed in the ER diagram. In the diagram, each ods:Identification has only one ods:TaxonIdentification, whereas according to the definition here, it can have multiple.
From our perspective it makes more sense to only have one TaxonIdentification connected to the Identification class, as the DigitalSpecimen could have multiple Identifications. The way it is set up, the Identification says who did the identification and when and the taxon identification is the result (there could other identification types in the future, e.g. for geological identifications). Having a second result to the same identification event, doesn't really make sense and in the rare cases where this might be useful, it can also be modeled as two separate identifications by the same person on the same date.
If this is adjusted and only one TaxonIdentification is allowed per Identification, then the term needs to be renamed to be aligned with the naming convention, which would be TaxonIdentification. If the changes proposed in #169 are accepted, then the name can remain as it is and the term only needs to be adjusted in with its structure and definition.
The text was updated successfully, but these errors were encountered: