Hi Iain,

I will begin with a little clarification and then I will kick up some mud.

To answer your questions
- the determiner is not always the recorder (although that is often the case).
- the verifier is rarely the person who does the species identification.
- the recorder_names could all be active contributors of occurrence records.
- the created_by_id (or the updated_by_id) is the warehouse user id of the user entering the data.

Eg. Janet and John go out to do a butterfly survey. Janet and John both contribute to the list of species they see. Janet is the more knowledgeable and identifies most of the species except for one she does not know. They take a photo and ask their friend Tom what it is. Tom is able to identify it for them as a Clouded Yellow. Since Janet and John don't have a computer, another friend, Dick, enters the data online for them. Janet and John were recording for a survey by Butterfly Conservation and their record is now reviewed by Harry, the county recorder. Automated checks done by the warehouse confirm all the records are within know flight period and distribution and are of easily identified species except for the Clouded Yellow. Harry is happy to accept all of these common species and add them to the verified dataset that will go to the NBN Gateway. The Clouded Yellow is unusual so Harry talks to Tom about it and is satisfied that this is indeed correct so accepts that too.

Janet and John are both recorders.
Janet is the determiner for all the occurrences except the Clouded Yellow.
Tom is the determiner of the Clouded Yellow.
Dick is marked as having been the creator of the record in the database.
Harry is the verifier.

authenticate_user does return the warehouse user id in the circumstance where the warehouse is being used to authenticate login of users to a client website. Most Indicia users have Drupal as the framework for their client websites and in their case, Drupal manages user authentication and the EasyLogin module, using the user_identifier web service, obtains the user id.

Now to muddy the water.

Indicia does, optionally, support the possibility of a forum of people arriving at a determination, like iSpot does. There is a determinations table which can record the opinions of any number of people about the identification of a particular occurrence.

The comment on the recorder_names field says " Used when the recorders are not listed in the people table." but I do not understand what we are expected to do if the recorders are listed in the people table.

Often the recorder_names field seems too unstructured and sample_attributes are created for first name and last name. When using sample attributes like this, there is a "system function" property that can be set to indiciate the purpose of these fields. That is something I don't have much understanding of.

Often form builders assume that there is only one recorder and that they are doing their own data entry. In this case, rather than storing a recorder name in the sample, the created_by_id may be considered sufficient.

Jim Bacon.

Another bit of muddiness I remembered.

Since neither Tom nor Janet have ever done anything that has added their details to the warehouse tables they have no id which could go in the determiner_id field. The obvious workaround is to create a text occurrence attribute in which to write the determiner name.

Since Dick sometimes write Thomas rather than Tom, this field is not very useful as a filter in database queries but it provides some help to Harry when he is verifying.

Jim Bacon.

Hi Iain

Have you found the  User Identifiers Web Service documentation? Does it answer your question?

Jim.

Hi Iain,

Haven't a clue!
However I might know where to take a look.
Try the warehouse in modules/indicia_svc_security/controllers/services/user_identifier.php.
Lo and behold we find the private createUser function.
The one public function that is exposed is get_user_id and use of this is documented under Security Services API although an additional, shares_to_prevent, parameter is described in the code.

Jim.