hiscom/business

Document the community's preferred technical specification for linking annotations to occurrence records

Closed this issue · 12 comments

Document the community's preferred technical specification for linking annotations to institutional and/or AVH occurrence records. The resulting document should be in HISCOM's Business wiki.

Linking annotations to occurrence records is trivial, as the Occurrence is the target (https://www.w3.org/TR/annotation-vocab/#hastarget) of the Annotation.

What I would like us to do – and the only thing HISCOM should do – is write a document with use cases for annotations we can think of.

I thought the discussion about annotations is bigger than linking to occurrence records, it was also about 'notifying' other institutions who have replicates about changes to in the data in such away that allows them to OPTIONALLY adopt these into their own application ie. address the issues of double handling data, improving data quality etc.

We need to think a bit farther out of the square, as all that is also already available in the current ALA implementation as Ben concluded in his talk at the ALA symposium three years ago (and see https://api.ala.org.au/).

The power of annotations is in the fact that you can use them to say things about the data without actually changing the data, so it can be used to add value. At the moment quality control is the only thing ALA annotations can be used for and then only in a very limited way (you can only say that the identification is definitely wrong or the georeference is definitely wrong).

In VicFlora we use annotations to clean up the maps, i.e. asserting that an occurrence in a certain location is doubtful, in which case it won't be shown on the map, or giving establishment means for records that don't yet have it (or if we don't agree with the value given). So we have several thousands of annotations that would add value to AVH records, but we can't deliver them to ALA, as their implementation cannot handle them (too simplistic).

We will also (try to) use annotations in combination with the W3C Media Fragments to tag areas in an image (of a herbarium specimen), so that when we link to it from a key (for example) it will immediately zoom in to the relevant area and, optionally, provide information specific for that area.

There are a lot of things that can be done with annotations. The W3C Web Annotation Data Model makes for good reading.

@afuchs1 @nielsklazenga Can we change the title of this issue? I agree that it is wider than the discussion(s) we've already had -- my conception was that we set down what we want ideally, and then work towards that.

@ben3000 Yes, that is what I was hinting at in my first comment.

The vendors of specimen collection systems need to get on board with use of ALA's Assertions API.

ALA data quality project Data profiles functionality, the default data profile filters out records with unanswered user annotations based on the fq=-user_assertions:50001 AND -user_assertions:50005

https://biocache-dq-beta.ala.org.au/occurrences/search?taxa=

As it is wider than just ALA's Assertions API, we need to document what standards we recommend and why. This answer of Niels' and an earlier one of mine are a reasonable starting point.

HISCOM AGM discussion
Miles is addressing annotations in ALA Data Quality project and will be looking for feedback. HISCOM is to consider - what does the community want out of it? And why? We decided to workshop some use cases both from the MAHC and HISCOM perspective. These use cases are to be recorded in github. Some requirements to consider that were raised included ingesting annotations into our insitutional systems; response to/closure of annotation back to ALA.

Niels has set up a a folder and [template] (https://github.com/hiscom/business/blob/master/annotations-use-cases/use-case-template.md) to document use cases for annotations in ALA.

Closed issue in relation to preferred technical implementation, it has been discussed in comments above and should be addressed in the ALA project. Opened #91 to document use cases.