Paul has drafted and circulated to James and Bob a draft Annotation interest group charter for submission to TDWG.
All the discussion about schema has been put into schema annotations of AnnotationMessage.xsd.
Discussion of citation of annotations. What's needed, e.g. GUIDs?
What's needed for releasing for feedback. Bob: need a proposed normative, representation-free, set of facets.
APIs for FP queries
Annotator may need be a complex type or GUID. Looking for the parallel concept in TDWG standards.
Annotations probably need GUIDs. Assertions within annotations need to be identifiable. Assertions within annotations might need to be ordered.
Annotation typing a significant issue for discussion. Typing involves three different concepts: Actions, Required elements, Because. An annotation might suggest (but not require) that a user act upon it by performing an insert, update, or group action. An annotation (much discussion of loaded vocabulary) might need to carry a particular set of domain concepts in order to make a sensible assertion within that domain, e.g. a new identification of a specimen involves a scientific name, a determiner, and a date of determination - sets of domain concepts needed to make particular types of assertions partake of both the domain and the idea of annotation, and involve both the semantics of the data and client end validation of user input for some kinds of actions (alternate example, correction of dwc:country with ISO language code). "Because" annotations can incorporate both domain concepts that carry the assertion in the annotation, and other elements (possibly also domain concepts) that describe why the annotator is making the assertion - taking correct action on annotations may require understanding which elements of the annotation are assertions about the data, and which are meta-assertions justifying why the annotation was asserted (the "Because" elements).