Create end user documentation

[javier-molina]

What's need it.

Overview - Entry point for help articles Specific pages with more detail

What we want to communicate:

@RobinaSanderson to fill in and/or break down in multiple tickets as she sees fit.

[RobinaSanderson]

Conversation with @brucehyslop about resources for field changes and assertion changes:

Field changes

• there is a page in production that provides current field names
• there is a service which provides a .csv file. This will be updated to provide current field names and deprecated field names, and any new field names - https://aws-biocache-quoll.ala.org.au/ws/index/fields.csv&deprecated=true Note: where there is a new field name it is in effect a name change, where there is no new field name the field itself is deprecated
• field names have both a mapping and a reverse mapping. This means an end user can query the service using an old field name, the service will search using the new field name, any results will appear in a JSON file using the old field name

Assertion changes

• there is a service that provides a JSON list of current assertion names
• We are not sure if we can get a .csv of new and old assertions - to be checked with Alex
• assertions have a mapping from old to new, but not new to old. This means a user can search with the old names, but results will be provided using the new names

(Bruce, could you check that I've not misunderstood anything above?)

At a minimum we need a separate knowledge base article explaining the above with the following:

• Link to the page with all current field names
• Link to the .csv file with all names
• Static excel derived from the .csv of changed field names
• Static excel derived from the .csv of deprecated fields
• Link to service providing current assertion names
• Static excel of current assertions
• Static excel of checnged assertions
• Static excel of deprecated assertions

It would be good to be able to provide all (old and new) assertions in .csv this would make it consistent with field names. It would be good to be able to compare assertions in Prod with assertions in pipelines to ensure we haven't missed any.

[RobinaSanderson]

Major changes overview knowledge base article

Listing of benefits:

• Ability to deal with greater volumes.
• Ability to process things more quickly
• aligning processing with GBIF so records should be more consistent

Ingestion

• Won't be doing partial updates to data, instead reingest the entire dataset - should introduce less error and make changes to data to track
• Will retain more robust linkages between occurrence records and associated images as they can be ingested together as a single DwCA (this may be completely wrong....)

Searching for and accessing records

• field and assertion changes (see above comment)
• will there be any other changes to the download process?
• changes to geospatial kosher
• removal of habitat_mismatch assertion and species_habitat field
• change to how Biome field is populated
• (Check gaps github issues and confluence listing for more)

Any changes to how images are displayed or spatial portal functions????

[RobinaSanderson]

Knowledge base articles have been written and published see confluence for drafts and Freshdesk for articles. https://support.ala.org.au/support/solutions/articles/6000249563-ala-infrastructure-changes-2021 https://support.ala.org.au/en/support/solutions/articles/6000249564-how-to-use-facets-to-filter-ala-data https://support.ala.org.au/en/support/solutions/articles/6000249686-how-do-i-search-and-filter-for-environmental-dna-edna-records- https://support.ehelp.edu.au/a/solutions/articles/6000249565?portalId=6000061612

There are github data quality wiki pages for all the assertions and fields used by the data quality filters. See https://github.com/AtlasOfLivingAustralia/ala-dataquality/wiki

@javier-molina - I think this can now be closed.