requirements related to 'flags' on records

[heathercole]

I would like to review the types of 'flags' that collection managers may require in the database, but wanted to check in here first.

From my perspective, there are a few options

1. a different field/checkbox for each type of flag required
2. one field with a picklist (controlled vocabulary, that collection managers can edit/add if necessary)
   • this case, I would think that there would be a set "reason/action" associated with each value (attributes added if new value added to picklist) that would inform #89
3. ???

My first thought is that maybe option 2 is most straightforward? I would like to propose it (something else??) to all the managers to see if it meets all their requirements. For this issue, I thought having the WP3 perspective first would structure effective feedback. (happy to discuss in a meeting with relevant smaller WP3 group)

other info: This also relates to #89 in the sense that there may be different implications for the media objects associated to flagged records.

Examples.

1. There are CITES species that collection managers need to track in their databases to be aware of loan/management restrictions, but the data and associated media objects are still "open"
2. there are sensitivity/security related restrictions on a species, the data and associated media objects should not be publicly available
3. records collected from certain countries before/after certain dates, as relates to Nagoya Protocal, specimen collection data may be ok to leave on portal, but not DNA sequences.

[heathercole]

Collection managers have discussed requirements for this. Related issues #56 and #89

We generally concluded that there is a need for "tags" and for "flags". This may not be the completely correct terminology, but from our perspective:

• "tags" relate to additional info associated to a record, but do not require "action/function".

  • Eg. CITES-listed species
  • offensive terms included in records (some common names/place names)
  • red-lists

• "flags" relate to additional OR existing fields in which a particular value may require particular functionality/action

  • eg. CCFC has a field which identifies the specimen is dead/gone, then this would require the record NOT being shared on the public portal

          - CNC researcher is working on a particular taxon group and those records (unpublished) should not be made public in the moment, but will be later

other types of records that may need tags/flags

• missing data

• sensitive/restricted taxa

• ongoing projects

• based on collection location/data (eg. Nagoya)

• records with Intellectual Property implications

• controlled specimens

• +other

• actions/outcomes relating to the flags must be also applied to associated media objects

• need (regularly scheduled) system generated checks against resources (CITES list, offensive terms, red-list) BUT also that managers can edit the same fields. If managers edit a field, then their entry should NOT be over-written the next time the check is run

[heathercole]

@dshorthouse @gobeilt Not sure if you have seen this update; some documentation of requirements about fields or records may be restricted from the public portal or flagged/tagged for collection managers.

Though it was more common-place in the past, there are not currently any requirements for hiding coordinates specifically, though possibly other reasons for records to not be public.

[heathercole]

related to today's 'georeferencing' discussion, there could easily be multiple objects linked to the same collection event in which some may be flagged and others not. Particular taxa collected at a particular place/time may need to be flagged (eg. NAGOYA) while other taxa from the same place/time may not need flags.

There are many such flag/tag requirements, each collection manager will be happy to provide more info.

[cgendreau]

Done by combination of publicly releasable, tags and managed attributes