Annotate Specimen

From Filtered Push Wiki
Jump to: navigation, search


Use Case: Annotate Specimen

Or, Make Annotation, which seems more general, applying to images or other media files vouchering observations as well as specimens.

Note: this use case should be divided into several, particularly the use case for eliciting a new annotation from a user and the use cases for ingesting an annotation at an authoritative data source.

Business Process

Goal: Data about specimens in natural history collections is being brought to the desktops of the researchers and specialists best able to correct and clean those data, without those researchers being brought back in to the specimen collections themselves. The visits of researchers to collections and the annotations of specimens by researchers is one of the key processes that keeps collections and their data vital, alive, and current. A critical need in the growing global networks of specimen data is a means for corrections, annotations, and new identifications (all of the processes of data improvement that keep natural history collections vital) to be brought from the remote desktops at which those data are seen back to the collections that hold the specimens.

Summary:

Diagram

Annotate specimens use case diagram.png

Note: Not in diagram is the creation of automatic filtering rules by the User, or the application of those rules to auto accept or auto reject messages with particular characteristics.  ?separate use case?

Note this use case should be divided into several, particularly the use case for eliciting a new annotation from a user and the use cases for ingesting an annotation at an authoritative data source.

UseCaseDiagram injectAnnotation Fig147213.png

UseCaseDiagram InjestAnnotation Fig147085.png

Actors

Taxonomist (a taxonomist or other researcher at a remote data portal, able to contribute a correction or new information related to data that they are seeing at that portal. Taxonomist here comprises both the human and the portal software (which may be a web portal or a collection database)).

CollectionDatabase (the software that manages and communicates with an authoritative database containing information about physical or electronic vouchers of organisms, such as the specimen catalog of a zoological collection in a natural history museum, or a database of field images of organisms).

User (a collection manager, or other gatekeeper for the collection database, the human filter for the acceptance or rejection of annotations directed towards their collection database.) Sometimes termed the Data Curator.

Preconditions

Data about specimens are present in the FP network.

Triggers

Taxonomist sees an error or has new information that relates to a collection object or defined set of collection objects.

Course of Events

  1. The Taxonomist enters structured data comprising an annotation. The Taxonomists injects the new annotation into the network. Note on addressing: the taxonomist doesn't know the network address of the destination node, but provides enough information in the annotation for there to be a high likelyhood of the network being able to find the correct address. The taxonomist provides either a GUID (through the software) or a darwin core triplet for the record to be annotated.
  2. The network retains knowledge of the annotation and forwards it to the user who is the gatekeeper of the institution that holds the authoritative record for the specimen or observation that is being annotated. Note on addressing: The network infers the destination of the annotation from the content of the annotation, this annotation is about MCZ-Ornit-35151, destination must be the MCZ node.
  3. The gatekeeper may accept the annotation, in which case the data are transformed to fit the local schema and pushed into the authoritative local database.
  1. Notice of the acceptance of the annotation is injected back into the network.

Alternative Paths

The annotation is on a set of collection objects and is forwarded to the gatekeeper of each institution holding one or more members of the set.

The gatekeeper rejects the annotation. No change is made to the local database, and notice of the rejection is injected back into the network.

The gatekeeper agrees with and accepts the annotation. Notice of the agreement and acceptance of the annotation is injected back into the network.

The gatekeeper disagrees with but still accepts the annotation. Notice of the disagreement and acceptance of the annotation is injected back into the network.

The gatekeeper agrees with but still rejects the annotation. Notice of the agreement and rejection of the annotation is injected back into the network. No change is made to the local database.

The gatekeeper ignores the annotation. No message is sent to the network. No change is made to the local database.

The annotation is for a specimen that isn't on the network because the collection isn't on the network. The network retains knowledge of the annotation. This could also be an error condition, it is a case where the network can't determine the destination address for the annotation. This should thus probably generate a message back to the annotator.

The annotation is for a specimen that isn't on the network because the specimen hasn't had its data captured yet. Message goes to destination node, handling is dependent on gatekeeper.

Potential alternative path: The content of the annotation undergoes automated quality control analysis, problems are found, and a FP_Messages#FP_QUALITY_ISSUE_ASSERTION message is generated referring to the original message.

Postconditions

The annotation is stored as part of the authoritative record of the relevant specimen.

The network retains knowledge of the annotation and its status.

Business Rules

Annotations must contain enough information to determine destination address.

Assumptions

Taxonomist knows which specimen (or specimen set) to annotate. That is, the taxonomist can address an annotation to a particular collection object (which needs to be know to the portal through some GUID or through a set of concepts that form a likely likely identifier for a single collection object (a darwin core triplet)).

Notes

The annotation use case suggests three specific types of messages for the injection of an annotation into the network, and an additional message injected back into the network at a filtering endpoint in response to one of these messages. One annotation message is a New Determination, a message carrying an identification to some level in the taxonomic hierarchy made by some person about some voucher of some organism based on their remote observation of data concerning that organism (e.g. A taxonomist provides a new determination of a specimen in a museum collection based on their viewing of an image of that specimen). A new determination is made by someone at some time (which may not be the person or time of the injection of the new determination message into the network), applies to some thing, identified by a globally unique identifier or by a DarwinCore triplet of institution, collection, and catalog number. A new determination message requires a TaxonName, mappable as a DarwinCore TaxonName element, and can contain any of the taxon name related DarwinCore elements, or TaxonConceptSchema elements. Mapping local concept spaces onto the required and optional elements of the new determination message is the job of the mapping interface. A new determination for a specimen injected into the network is forwarded to the network node associated with the institution holding that specimen, where it is expected to be queued for examination and filtering. The new determination is remembered by the network and can be retrieved from the network in association with the data for the referenced specimen, even though the annotation may still be pending review. On receipt, a human (or a set of filtering rules, e.g. Automatically reject all annotations from some person), can examine the new determination in a local software system (our goal in the prototype, is from within the Specify user interface), and then can inject a message back into the network making an assertion about the annotation. Such response messages may accept the annotation, indicating its acceptance into the local authoritative data store without commenting on its validity – someone said this, I trust them, I've accepted their statement- or agree with the annotation – someone said this, I agree with them, I've accepted their statement – or reject the annotation.