Making Annotations, The James Scenario

From ETaxonomy

Examining scenarios, linking in messages and refining to use cases from Use_Case_Scenarios#Making_Annotations

1

James the knower of all things Rubus is curious how Henry is progressing. He opens a report in Specify that shows him that Henry input 37 specimens today. External

James then goes to an UI that shows him any records from Henry that were flagged. External

James notices that one of the records has a lat/long that is screwy and realizes that he has the field notes for this particular collection and looks up the collecting event. External

He realizes that the lat/long is incorrect for all duplicates input and he makes a revision. He submits the change to the UI.

  Message: Annotation: FP_Messages#FP_CORRECTION_ASSERTION
  Annotator:James Macklin
  Applies to: {UniqueIdentitifier for this set of duplicates}
  Latitude 35.5125
  Longitude 72.6423
  Error Radius: 300m
  Source: Manual, from examination of field notes and contemporaneous USGS Topo quad.
  

James leaves content that he has done a great service to his colleagues in notifying them of this mistake. External (or is it, see the note below about accumulating histories of what happens to annotations produced by particular sources.)

Rich, my good friend at UMICH, goes to his Specify UI and sees that James has made a change External, a Description of the receipt of the annotation message.

  Implicit in the above creation of an annotation that references a set of duplicates is 
  resolving the reference to the set of duplicates to which this annotation applies, 
  and providing the annotation to each node that holds a member of the set.
  Requirement: users can see pending annotations addressed to their institution.

and since it is on Rubus which Rich implicitly accepts knowing that James knows all in this regard.

  Message: FP_Messages#FP_ASSERT  Assert accept.
  There is also an implication here that Rich might set a automatic rule based on this annotation - accept all annotations from James about Rubus.  
  This might need a new class of message to create a filter rule, or this might be external.

  Requirement: Users can extract structured data from the network and save it into their local data stores.

1.1.

The next day, after sleeping on it, James wonders just how many similar errors there may be for Rubus records on the network. External

So, James uses the UI to see a list of all Rubus in taxon A according to the label identification.

  Message: FP_Messages#FP_FIND_SETS
  Genus = Rubus 
  Specific epithet = "taxon A" or Infraspecifc epithet = "taxon A"  [alternately, epithet = "taxon A"]
  Message: FP_Messages#FP_GET_DATA

In looking through these James identifies a few more mistakes by mapping the georeferenced records. External

  Note that "James identifies" is easily extended to James uses the FP network to find outliers by generating a message to conduct an analysis.
  Thus, FP_Messages#FP_ADD_SET_GENERATION_RULE and FP_Mesasages#FP_BUILD_SETS could both be relevant here.

James also makes these corrections and submits them.

  Message: Annotation: FP_Messages#FP_CORRECTION_ASSERTION

1.2.

The next day, James again looks to the reporting agent that tells him what is new with records relating to his collection. James decides to spend a few hours looking at these. James sees there has been several entries on Aster which are new and interesting. James accepts these annotations and the metadata associated and flags them in the UI which moves to a queue to print. When a page of these annotations is accumulated the document is printed and James cuts the annotation labels out. James then takes the Aster annotations and goes into the collections and finds the corresponding sheets and glues the labels on and refiles the specimens appropriately as identified.

4

A taxonomist viewing an image in Morphbank of a specimen held in HUH (but deposited by someone else into morphbank) External

enters a new determination of that specimen into morphbank.

  Message: Annotation: FP_Messages#FP_NEW_DETERMINATION

The new determination (and the identity of the taxonomist) is sent to HUH

  Requirement: Messages carry assertions about the person responsible for generating the message.
  Requirement: Annotations about a specimen can be delivered to the institution holding that specimen.

and presented to Henry in his list of pending annotations.External

Henry accepts the annotation (notifying the network of this),

  Message: FP_Messages#FP_ASSERT

prints a label, and associates it with the specimen. External

Another taxonomist queries the network

  Message: FP_Messages#FP_FIND_SETS

  Requirement: The network can query and obtain information from local data stores outside the network.

and can find the specimen directly from HUH under the new determination.

  Message: FP_Messages#FP_GET_DATA
  Requirement: The content of accepted annotations is discoverable by users.
  Unspecified: Is the existence of accepted annotation messages discoverable by users? 

4.1.

As in the above,

  Message: Annotation: FP_Messages#FP_NEW_DETERMINATION

except Henry never gets to the annotation.

  Requirement: Annotations may or may not be acted upon.

Another taxonomist queries the network and can still find the specimen under the pending annotation, even though HUH hasn't accepted the annotation.

  Requirement: The existence of and content of pending annotations is discoverable by users.
  Message: FP_Messages#FP_FIND_SETS
  Message: FP_Messages#FP_GET_DATA

4.2

As in the above,

  Message: Annotation: FP_Messages#FP_NEW_DETERMINATION

except that James tells Henry to reject the annotation. Henry doesn't print a label, External

and tells the system to reject the pending annotation.

  Message: FP_Messages#FP_ASSERT
  Content: This particular annotation message was rejected by Henry at HUH.

The system tells morphbank that the annotation was rejected.

  Requirement:  The originator of an annotation is notified when that annotation is rejected.
  Message: FP_Messages#FP_NOTIFICATON

  Unspecified: Is the existence of or content of rejected annotations discoverable by users? 

Note on discovery of the existence of processed (accepted or rejected) annotations - retention and discovery of acceptance and rejection might be of use for scoring the reliability of sources of annotations (as would the ability of users to discover other users rules for automatic actions on annotations).

4.2 Modified - needs more thinking out in the context of community messages.

As in the above except the person who generated the annotation asks to be told when the annotation is acted upon,

  Message: Annotation: FP_Messages#FP_NEW_DETERMINATION
  Message: FP_Messages#FP_SUBSCRIBE   

  Unspecified: How does the annotator subscribe?  What is the annotator's return address? 

except that James tells Henry to reject the annotation. Henry doesn't print a label, External

and tells the system to reject the pending annotation.

  Message: FP_Messages#FP_ASSERT
  Content: This particular annotation message was rejected by Henry at HUH.

The system tells morphbank that the annotation was rejected.

  Requirement:  The originator of an annotation is notified when that annotation is rejected.
  Message: FP_Messages#FP_NOTIFICATON - delivered to morphbank
  Message: FP_Messages#FP_NOTIFICATON - delivered to the originator of the message At what address?